230 likes | 345 Views
The XSS Files. Find, Exploit, and Eliminate. Josh Little. Security Engineer at global vertical market business intelligence company. 9 years in application support, developer relations, and application review. OWASP Detroit Chapter Leader & a # misec founding member GSEC, CISSP in limbo.
E N D
The XSS Files Find, Exploit, and Eliminate
Josh Little • Security Engineer at global vertical market business intelligence company. • 9 years in application support, developer relations, and application review. • OWASP Detroit Chapter Leader & a #misec founding member • GSEC, CISSP in limbo
What is a XSS flaw? • XSS = ‘Cross Site Scripting’ • Injection of arbitrary code into a user’s browser session • #2 on the 2010 OWASP Top 10 and has been on the list since the beginning
Causes of XSS Flaws • Failure of the application to properly sanitize output to the user’s browser. • Improper trust of of user supplied data. $a = $_GET['search']; print 'Your search results '.$a;
Effects of XSS • Theft of session cookies • Arbitrary HTML or Javascript injection • Exploit injection • Keystroke Logging • BeEF & Metasploit can be used to show effects of XSS
Reflective vs. Persistent • Reflective – Payload tied to specific URL. Visit the link, hit the payload. • Persistent – Embeds the payload into the page (think comments, forum posts, etc.)
DOM Based XSS • XSS based on the DOM's (Document Object Model) response to the incoming code and other page/request elements. • Does not require dynamic server-side code. <script> document.write("Site is at: " + document.location.href + "."); </script>
Finding XSS Flaws • Basic test: • Determine how application handles 'special' characters such as " ' < > • If the application returns these characters unencoded, it's possibly (and probably) vulnerable.
Automated scanning – Can test a large number of test cases quickly. Not complete, but a good method to find low-hanging fruit quickly. Source Code Review – Unsanitized use of input is fairly self evident in code review. Time consuming, however, and complex code can make it difficult to follow input paths. As with other flaws, a multi-pronged approach is best.
Preventing XSS • Input whitelisting • Context sensitive output encoding • Javascript, Actionscript, HTML, CSS, etc. must all be treated differently. • Just encoding for HTML will not prevent all issues.
Context is Key *courtesy of Jim Manico (@manicode)
To be truly successful, sanitization should be part of the development framework and not optional. Most successful when the decision on whether to apply sanitization is not up to the individual developer but enforced by the development environment.
Anti-XSS Frameworks • .NET – MS AntiXSS Libraryhttp://msdn.microsoft.com/en-us/security/aa973814 • JAVA, .NET – OWASP AntiSAMYhttps://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project • Javascript – Google CAJAhttp://code.google.com/p/google-caja/
Browser Based Defenses • Most modern browsers have some form of XSS protection either built-in or via a 3rd party plugin (i.e. NoScript) • Bad code is still bad code – don't rely on the browser for defense.
Basic XSS Examples Demos
Demos • All demos are available at http://xploit.zombietango.com/xss • Feel free to play with them and use them in additional demonstrations.
#1 Basic XSS & Mitigation Strategies • http://xploit.zombietango.com/xss/1/ • Mitigation Strategies: • Basic – Strips <script></script> tags • Good – Encodes output within HTML context • Textarea – Encloses error message in a <textarea> tag
#2 Attacking incomplete filtering • http://xploit.zombietango.com/xss/2/ • No input written to page body, so we're safe, right? • Search term written to <title> tag without sanitization
#3 XSS with Style • http://xploit.zombietango.com/xss/3/ • Don't confuse limited means of input with limited input • Some apps respond to multiple HTTP methods • Cookies can provide a method of persistence within a user's browser session.
#4 DOM Based XSS • http://xploit.zombietango.com/xss/4/ • Site builds comment link with ref to current URL. • # tag in URL before payload prevents attack from showing up in server logs
#5 XSS through POST • http://xploit.zombietango.com/xss/5/ • Apps using only the POST method are not immune to XSS • Requires the use of secondary page to build & submit the exploitable form