Security. CSC309 TA: Sukwon Oh

Similar documents
WEB SECURITY WORKSHOP TEXSAW Presented by Solomon Boyd and Jiayang Wang

Attacks Against Websites. Tom Chothia Computer Security, Lecture 11

CHAPTER 8 CONCLUSION AND FUTURE ENHANCEMENTS

NET 311 INFORMATION SECURITY

Advanced Web Technology 10) XSS, CSRF and SQL Injection

Application vulnerabilities and defences

RKN 2015 Application Layer Short Summary

Information Security CS 526 Topic 8

Web Security: Web Application Security [continued]

Your Scripts in My Page: What Could Possibly Go Wrong? Sebastian Lekies / Ben Stock Martin Johns

Secure Coding and Code Review. Berlin : 2012

WEB SECURITY: XSS & CSRF

Web Security. Thierry Sans

Lecture 17 Browser Security. Stephen Checkoway University of Illinois at Chicago CS 487 Fall 2017 Some slides from Bailey's ECE 422

PROBLEMS IN PRACTICE: THE WEB MICHAEL ROITZSCH

Web Security. Jace Baker, Nick Ramos, Hugo Espiritu, Andrew Le

Information Security CS 526 Topic 11

IERG 4210 Tutorial 07. Securing web page (I): login page and admin user authentication Shizhan Zhu

Web Application Security. Philippe Bogaerts

Client Side Injection on Web Applications

Web Security IV: Cross-Site Attacks

Some Facts Web 2.0/Ajax Security

CS 161 Computer Security

CSCD 303 Essential Computer Security Fall 2018

CSCD 303 Essential Computer Security Fall 2017

Perslink Security. Perslink Security. Eleonora Petridou Pascal Cuylaerts. System And Network Engineering University of Amsterdam.

Web Penetration Testing

Common Websites Security Issues. Ziv Perry

Web Vulnerabilities. And The People Who Love Them

Web Security: Vulnerabilities & Attacks

Web Security: Vulnerabilities & Attacks

s642 web security computer security adam everspaugh

SQL Injection. EECS Introduction to Database Management Systems

Computer Security CS 426 Lecture 41

JOE WIPING OUT CSRF

Web Application Security

Web Application with AJAX. Kateb, Faris; Ahmed, Mohammed; Alzahrani, Omar. University of Colorado, Colorado Springs

JOE WIPING OUT CSRF

Web 2.0 and AJAX Security. OWASP Montgomery. August 21 st, 2007

CS 155 Project 2. Overview & Part A

Code Injection Attacks

Security and Privacy. SWE 432, Fall 2016 Design and Implementation of Software for the Web

Web Security. Aggelos Kiayias Justin Neumann

CSE361 Web Security. Attacks against the client-side of web applications. Nick Nikiforakis

This slide shows the OWASP Top 10 Web Application Security Risks of 2017, which is a list of the currently most dangerous web vulnerabilities in

Cross-domain leakiness Divulging sensitive information & attacking SSL sessions Chris Evans - Google Billy Rios - Microsoft

NoSQL: NoInjections or NoSecurity

CS Paul Krzyzanowski

Computer Security. 14. Web Security. Paul Krzyzanowski. Rutgers University. Spring 2018

CSRF in the Modern Age

P2_L12 Web Security Page 1

Attacks Against Websites 3 The OWASP Top 10. Tom Chothia Computer Security, Lecture 14

Development of Web Applications

Avoiding Web Application Flaws In Embedded Devices. Jake Edge LWN.net URL for slides:

Databases/JQuery AUGUST 1, 2018

welcome to BOILERCAMP HOW TO WEB DEV

eb Security Software Studio

Web basics: HTTP cookies

Web basics: HTTP cookies

CSE 127 Computer Security

Clojure Web Security. FrOSCon Joy Clark & Simon Kölsch

How is state managed in HTTP sessions. Web basics: HTTP cookies. Hidden fields (2) The principle. Disadvantage of this approach

WHY CSRF WORKS. Implicit authentication by Web browsers

Application Security through a Hacker s Eyes James Walden Northern Kentucky University

Application Security Introduction. Tara Gu IBM Product Security Incident Response Team

CSE 484 / CSE M 584: Computer Security and Privacy. Web Security. Autumn Tadayoshi (Yoshi) Kohno

Security for the Web. Thanks to Dave Levin for some slides

Lecture Overview. IN5290 Ethical Hacking

Lecture 6: Web hacking 2, Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), Session related attacks

Your Turn to Hack the OWASP Top 10!

Computer Security 3e. Dieter Gollmann. Chapter 18: 1

Andrew Muller, Canberra Managing Director, Ionize, Canberra The challenges of Security Testing. Security Testing. Taming the Wild West

2/16/18. CYSE 411/AIT 681 Secure Software Engineering. Secure Coding. The Web. Topic #11. Web Security. Instructor: Dr. Kun Sun

CSC 405 Computer Security. Web Security

CIS 4360 Secure Computer Systems XSS

Chrome Extension Security Architecture

MongoDB. CSC309 TA: Sukwon Oh

WebGoat Lab session overview

CS 161 Computer Security

Web Attacks CMSC 414. September 25 & 27, 2017

CS526: Information security

Web Security. Web Programming.

Application Layer Security

Full Stack boot camp

BOOSTING THE SECURITY

Security for the Web. Thanks to Dave Levin for some slides

Varargs Training & Software Development Centre Private Limited, Module: HTML5, CSS3 & JavaScript

CSCE 548 Building Secure Software SQL Injection Attack

Robust Defenses for Cross-Site Request Forgery

IERG 4210 Tutorial 08

2/16/18. Secure Coding. CYSE 411/AIT 681 Secure Software Engineering. Web Security Outline. The Web. The Web, Basically.

COMP9321 Web Application Engineering

Backend IV: Authentication, Authorization and Sanitization. Tuesday, January 13, 15

The Hacker s Guide to XSS

CSE361 Web Security. Attacks against the server-side of web applications. Nick Nikiforakis

Web Security, Part 2

Application Design and Development: October 30

W e b A p p l i c a t i o n S e c u r i t y : T h e D e v i l i s i n t h e D e t a i l s

GUI based and very easy to use, no security expertise required. Reporting in both HTML and RTF formats - Click here to view the sample report.

6.170 Tutorial 7 - Rails Security. Prerequisites. Goals of this tutorial. Resources

Transcription:

Security CSC309 TA: Sukwon Oh

Outline SQL Injection NoSQL Injection (MongoDB) Same Origin Policy XSSI XSS CSRF (XSRF)

SQL Injection What is SQLI? Malicious user input is injected into SQL statements and evaluated by RDBMS

SQL Injection SQL stmts consists of 2 things: control structure SELECT, INSERT, WHERE, DELETE, data values 1, 2, 3,, str1, str2, str3,

SQL Injection Web applications typically contain control part of SQL statements sql_query = "SELECT pizza, toppings, quantity, order_day " + "FROM orders " + "WHERE userid=" + session.getcurrentuserid() + " " + "AND order_month=" + request.getparameter("month");

SQL Injection Web applications typically asks user for data part of SQL statements sql_query = "SELECT pizza, toppings, quantity, order_day " + "FROM orders " + "WHERE userid=" + session.getcurrentuserid() + " " + "AND order_month=" + request.getparameter("month");

SQL Injection What happens if a user inputs data+control part of SQL statements? Send GET request to: http://attack.me/attack1?month=0%20or%201%3d1 Result: SELECT pizza, toppings, quantity, order_day FROM orders WHERE userid=12345 AND order_month=0 OR 1=1

SQLI Protection Basic Idea Prevent all user inputs from changing control part of SQL statements Solutions ORM Parameterized Queries escaping user inputs (remove special characters)

SQLI Protection Django QuerySet (ORM).raw(stmt, params) (parameterized query) Node.js node-mysql module s escape() node-mysql-native module s prepared statements Tool https://github.com/sqlmapproject/sqlmap

What about MongoDB? Even though MongoDB doesn t use SQL, it can be vulnerable to injection attacks db.collection.find( {active: true, $where: function() { return obj.credits - obj. debits < req.body.input; } } ); db.collection.find( {active: true, $where: function() { return obj.credits - obj. debits < 0; var date = new Date(); do {curdate = new Date();}while(curDatedate<10000); } } );

Protection Don t use $where, mapreduce, group which accepts arbitrary JavaScript expressions security.javascriptenabled = false Escape all user inputs before passing to $where clause

Same Origin Policy Motivation Users visit many websites at a same time using browser tabs or multiple windows A webpage may include some JavaScripts to access its DOM and send AJAX msgs to its backend What if the script can also do same with other websites? A website must not steal sensitive information from another website opened by the same browser

Same Origin Policy Let users visit untrusted websites without those websites interfering with user s session with honest websites

Same Origin Policy What is allowed? GET/POST requests to different origins Not PUT, DELETE <script src= other domain/script.js > similarly including <img>, css, etc Relaxation Methods document.domain, CORS, JSONP

XSSI Cross-site script inclusion <script src= URL ></script> What is script s origin? Including document s origin; therefore, the document has full access to the script s content What if URL returns a dynamically created JavaScript instead of a JavaScript file?

XSSI <script src= http://yourapp.com/secret ></script> If http://yourapp.com/secret returns a JavaScript with sensitive data and some functions Functions can be replaced with attacker s version and sensitive data can be stolen If http://yourapp.com/secret returns a JSON array Attacker can override JSON array constructor to steal array contents

XSSI

XSSI Protection Do not support GET requests for script returning URLs <script src=... ></script> sends GET requests Use XSRF tokens (will talk later) Do not include sensitive data

XSS XSS enables attackers to inject scripts into webpages viewed by other users bypasses same origin policy Injected script can do many things steal cookies change appearance of webpages steal sensitive data displayed on webpages...

XSS There are mainly 3 types Reflected XSS Stored XSS DOM-based XSS They are different in how scripts are injected to webpages

Reflected XSS

Stored XSS

Injection Points query parameters form fields cookies HTTP request header DB filesystem PHP

XSS Protection Input validation Output validation HttpOnly option for cookies

XSS Protection express.js express-validator module sanitizer module xss-filters module and many more.. Django templates

XSRF XSRF makes a user to submit requests on behalf of the attacker

Why XSRF works? Same Origin Policy allows sending GET/POST requests to different origins hyperlinks, forms, script, img, css, etc User s browser automatically submits cookies for all requests Whether a user intended a request or forced by an attacker is unknown to websites!

XSRF Protection Give a secret token to a user and tell the user to submit it along with cookie on following requests Attacker cannot guess this token and therefore websites can tell if the user wanted to send a request or not

XSRF Protection

XSRF Protection

XSRF Protection express.js csurf module Django CsrfViewMiddleware

XSS Demo Setup: git clone https://github.com/sukwon0709/express.git cd express npm install npm install express-validator Running: node example/auth

XSS Demo Input <script>alert( you are hacked! );</script> to Username field

XSS Demo

XSS Demo To test fixed version using express-validator.. cp examples/auth/index.js examples/auth/index_bad.js cp examples/auth/index_fixed_xss.js examples/auth/index.js node examples/auth

XSS Demo Input <script>alert( you are hacked! );</script> to Username field

XSS Demo

XSS Demo Look at comments starting with XXX (soh) to see how to use express-validator module.

XSRF Demo Setup: 1. 2. 3. 4. npm install csurf Run node examples/auth again Open xsrf.html file on your browser Look at terminal output

XSRF Demo

XSRF Demo A user logged in to auth app by just opening xsrf.html page.

XSRF Demo To test fixed version using csurf module.. cp examples/auth/index.js examples/auth/index_xsrf.js cp examples/auth/index_fixed_xsrf.js examples/auth/index.js cp examples/auth/views/login.ejs examples/auth/views/login_xsrf.js cp examples/auth/views/login_fixed_xsrf.js examples/auth/views/login.djs Run with: node examples/auth open xsrf.html on your browser

XSRF Demo Browser shows:

XSRF Demo Terminal shows:

XSRF Demo Look at comments on index_fixed_xsrf.js and views/login.ejs to figure out what you need to do.