Is XSS Solvable?

Download Is XSS Solvable?

Post on 27-Jan-2015




1 download

Embed Size (px)


Slides from my LayerOne 2009 presentation on cross site scripting.


  • 1. IS XSS SOLVABLE? Don Ankney LayerOne 2009 Saturday, May 23, 2009

2. DISCLAIMER This presentation represents personal work and has notbeen approved or vetted by Microsoft. I am solelyresponsible for its content. Saturday, May 23, 2009 3. OUTLINE XSS as a generic injection attack. What makes XSS unique, why its important. Defendingagainst XSS in general. Web Application Defense One effective architecture design pattern. Toolto help. Where to go from here.Saturday, May 23, 2009 4. DEFINING THE PROBLEM Saturday, May 23, 2009 5. INJECTION FLAWS Anyinterpreted code can be injected: LDAP, XML, HTTP, XAML, PHP, Python, Ruby, and most infamously, SQL. XSSis simply another form of interpreter injection, usually using Javascript. Wecan solve it just like we would solve any other injection problem*. * except SQL injection -- we have a better solution there. Saturday, May 23, 2009 6. PREVENTING INJECTION Always keep track of your trust boundaries. Validate/sanitizeyour inputs. Properly encode your outputs. Use white lists, not black lists. Exercise the principal of least privilege. Validateyour assumptions. Saturday, May 23, 2009 7. TRUST BOUNDARIES User System FormsFiles headersservices cookiesProcesses ajax les Application Database SQLLDAP web data storesSaturday, May 23, 2009 8. WHY XSS IS DIFFERENT Most injection aws attack your server. XSS attacks the end user -- it runs arbitrary code in their browser. Thebrowser is behind your rewall and is acting within the users security context.Saturday, May 23, 2009 9. YOU CAN DO SOME NASTY THINGS WITH JAVASCRIPT Javascript can control what appears on screen. Javascript has access to your history. Sites often store session tokens in GET request. Javascript can intercept cookies. Javascript can enumerate your network. Saturday, May 23, 2009 10. XSS TAXONOMY Saturday, May 23, 2009 11. REFLECTED XSSAttack VictimAttackerAttack Web App URL stringBrowserXSS Victimbrowser submits an evil request that containsjavascript. Theweb application then reects that javascript backto the victim browser, which then executes it. Saturday, May 23, 2009 12. REFLECTED XSS Attack does not persist across users, sessions, or pages. It is only reected back to the user that submits themalicious url. Thisis relatively easy to detect remotely via a scanner/fuzzer.Saturday, May 23, 2009 13. PERSISTENT XSS Attack stringAttacker Webpage Database VictimWebpage XSS Anattacker stores an attack string in a web application. Visitors to that site access infected pages causingjavascript execution.Saturday, May 23, 2009 14. PERSISTENT XSS Can persist across user, sessions, and pages. Itdepends on application context and who can access theinfected pages. Very difcult to detect remotely via scanning/fuzzing. Thereare many paths through an application, scanning is toonoisy for a production system. Bestidentied by code analysis.Saturday, May 23, 2009 15. HYBRID XSSAttack Webpage Attack A AttackVictimAttacker Session DataURL BrowserXSS Webpage Attack B Victim browser submits evil url. Attack string is stored as session data. Session data is returned to browser on another page,executing javascript.Saturday, May 23, 2009 16. HYBRID XSS Attacks are not persistent across sessions. Attacks do persist across pages. Attacks may persist across users. Thinkabout whos online functionality. Extremely difcult to detect remotely. May require specic request sequences.Saturday, May 23, 2009 17. DETECTING INJECTIONFLAWS REMOTELYSaturday, May 23, 2009 18. SCANNING FOR REFLECTED XSS VULNERABILITIES Thisrequires a simple fuzzer. Sendan attack string. Checkfor appropriately encoded returns. The most difcult part is maintaining a current attack string list.Saturday, May 23, 2009 19. SCANNING FOR PERSISTENTXSS VULNERABILITIES Thissort of scanner is immature. Requiresmapping input cause vs. output effectwithout knowledge of application state. Apersistent XSS scan is extremely noisy. Eachform has to have unique data submitted inorder to map persistent data across the site. Runningan attack list against the mapped site createsone persistent record per attack string. Saturday, May 23, 2009 20. DETECTING INJECTIONFLAWS LOCALLYSaturday, May 23, 2009 21. AVAILABLE TECHNIQUES Staticcode analysis Examines the source code Dynamicanalysis Examines application stateSaturday, May 23, 2009 22. STATIC CODE ANALYSIS Manualcode review. Static code analyzers: Pixy(PHP) CAT.NET (ASP.NET) CodeSecure (Java/ASP.NET/PHP) Saturday, May 23, 2009 23. WHAT STATIC ANALYSIS CAN DETECT Inputsanitization Reallyonly boolean, doesnt evaluate quality. Output encoding Are both application (html) and character encoding explicit? Data ow Doesanything skip sanitization or encoding?Saturday, May 23, 2009 24. DYNAMIC CODE ANALYSIS The only way to consider application state. Rememberthat persistent and hybrid XSS are state-dependent. Internal representation of data is tied to risk. Therearent a lot of existing tools. Most existing are run-time IPS-style tools.Saturday, May 23, 2009 25. DEFENDING AGAINST XSS Saturday, May 23, 2009 26. THERE ARE THREE CONTROL POINTS FOR XSS Web BrowserApplicationDatabase IT InfrastructureXSS can be mitigated at all three points.Saturday, May 23, 2009 27. THE BROWSER Differentbrowsers will execute different code snippets. O9, IE6: FF2, O9: Currentbrowsers are much better than previous generations.Saturday, May 23, 2009 28. IT INFRASTRUCTURE Webapplication rewalls. Intrusionprevention systems. Webapplication sandboxes. All of these are signature-based defenses. Saturday, May 23, 2009 29. WEB APPLICATION DEFENSE Saturday, May 23, 2009 30. ITS ALL ABOUT PROCESSRequest Return SecurityDecode LogicEncode Checks Thisrequires a consistent and enforced architecturalapproach. JSP, PHP 3/4, and classic ASP dont lend themselves tothis approach.Saturday, May 23, 2009 31. DECODE YOUR INPUTAccept-Language: en-us,en;q=0.5Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Ifthe request specied an encoding, you might want to assume that encoding for parameters. HTTPdefaults to ISO-8859-1 Convert the request to your applications internal representation.Saturday, May 23, 2009 32. SECURITY CHECKS Thisis where you apply your whitelists. Remember the principal of least privilege and use the most restrictive patterns possible. Ifyou must accept markup tags, parse the tags and replace them with tokens. Considerwhitelisting any paths or URLs. Saturday, May 23, 2009 33. SANITIZING HTML Thereare a number of libraries available to do this for you. Microsoft AntiXSS(.NET), OWASP AntiSamy (Java, .NET, Python). HTMLPurier (PHP)Saturday, May 23, 2009 34. WRITING YOUR OWNSANITIZATION LIBRARY Whitelist HTML tags. Be as restrictive as possible. If allowing high-risk tasks (such as and ), consider whitelistingtheir targets. Replace all the allowed tags with symbols. Parse them for properties. Store them this way. Replace the symbols prior to encoding. This way, everything isconstructed in your code and not passed from the user.Saturday, May 23, 2009 35. ENCODE YOUR OUTPUT Most commonly, encode using html entities. Afterentity encoding, replace your tokens with actual tags. If the nal output is not html, encode accordingly. XMLif outputting AJAX, XAML, etc.Saturday, May 23, 2009 36. EXPLICITLY DECLARE YOURCHARACTER SET Your web server can do it for you: AddCharset UTF-8 .php (Apache .htaccess) If in doubt, override your web server: header('Content-type: text/html; charset=utf-8'); (PHP .htaccess) (ASP.NET) print quot;Content-Type: text/html; charset=utf-8nnquot;; (Perl) Saturday, May 23, 2009 37. DO YOUR SECURITY CHECKS ACTUALLY WORK? foreach ($_GET as $secvalue) { if ((eregi(quot;]*script*quot;?[^>]*>quot;, $secvalue)) || (eregi(quot;]*object*quot;?[^>]*>quot;, $secvalue)) || (eregi(quot;]*iframe*quot;?[^>]*>quot;, $secvalue)) || (eregi(quot;]*applet*quot;?[^>]*>quot;, $secvalue)) || (eregi(quot;]*meta*quot;?[^>]*>quot;, $secvalue)) || (eregi(quot;]*style*quot;?[^>]*>quot;, $secvalue)) || (eregi(quot;]*form*quot;?[^>]*>quot;, $secvalue)) || (eregi(quot;([^>]*quot;?[^)]*)quot;, $secvalue)) || (eregi(quot;quot;quot;, $secvalue))) { die (quot;

The html tags you attempted to use are not allowed b>

[ Go Back ]quot;); } } foreach ($_POST as $secvalue) { if ((eregi(quot;]*script*quot;?[^>]*>quot;, $secvalue)) ||(eregi(quot;]*style*quot;?[^>]*>quot;, $secvalue))) { die (quot;

The html tags you attempted to use are not allowed b>

[ Go Back ]quot;); } } This is actual code in a popular CMS. Saturday, May 23, 2009 38. TESTING ARCHITECTURALPATTERN IMPLEMENTATIONSaturday, May 23, 2009 39. VALIDATES INPUTSANITIZATIONWeb Fuzzerattack stringsSanitization Validator attack strings Stored strings TargetDatabaseApp Virtual MachineSaturday, May 23, 2009 40. VALIDATES OUTPUTENCODINGEndcoding Validator attack strings Database FuzzerStored strings attack stringsTargetDatabase AppVirtual MachineSaturday, May 23, 2009 41. [DEMO] Saturday, May 23, 2009 42. TOOL BENEFITS Findsfundamental problems in software design Morecomplex attacks rely on either sanitization or encodingto be broken. Detectspersistent XSS attack vectors. Ina dedicated VM, noise doesnt matter. Saturday, May 23, 2009 43. TOOL LIMITATIONS Only works with database-resident state data Cookies, header, etcare also valid XSS threats. Only works against HTML forms Canbe extended to include AJAX, headers, cookies, etc.Saturday, May 23, 2009 44. TOOL PLANS Move it from PHP to C#. Createa PM-friendly interface so that anyone can run it. Addauthentication integration: Webforms, OpenID. Expandit to include non-form fuzzing. Saturday, May 23, 2009 45. WHY IS THIS HARD? Legacyapplications and languages often