Your SlideShare is downloading. ×
0
IS XSS SOLVABLE?
                          Don Ankney • LayerOne 2009




Saturday, May 23, 2009
DISCLAIMER

         This presentation represents personal work and has not
         been approved or vetted by Microsoft....
OUTLINE
    • XSS           as a generic injection attack.

    • What               makes XSS unique, why it’s important....
DEFINING THE PROBLEM




Saturday, May 23, 2009
INJECTION FLAWS

    • Any  interpreted code can be injected: LDAP, XML, HTTP,
        XAML, PHP, Python, Ruby, and most i...
PREVENTING INJECTION
             • Always       keep track of your trust boundaries.

             • Validate/sanitize   ...
TRUST BOUNDARIES

                         User                                   System
                          Forms  ...
WHY XSS IS DIFFERENT


    • Most               injection flaws attack your server.

    • XSS   attacks the end user -- it...
YOU CAN DO SOME NASTY
          THINGS WITH JAVASCRIPT

    • Javascript           can control what appears on screen.

  ...
XSS TAXONOMY




Saturday, May 23, 2009
REFLECTED XSS
                                                           Attack
                                          ...
REFLECTED XSS


    • Attack             does not persist across users, sessions, or pages.

         • It is only reflecte...
PERSISTENT XSS
                                          Attack string
                               Attacker            ...
PERSISTENT XSS

    • Can           persist across user, sessions, and pages.

         • It  depends on application conte...
HYBRID XSS
                                                       Attack
                                                 ...
HYBRID XSS

    • Attacks             are not persistent across sessions.

    • Attacks             do persist across pag...
DETECTING INJECTION
                           FLAWS REMOTELY



Saturday, May 23, 2009
SCANNING FOR REFLECTED
            XSS VULNERABILITIES

    • This          requires a simple fuzzer.

         • Send    ...
SCANNING FOR PERSISTENT
           XSS VULNERABILITIES
             • This        sort of scanner is immature.

          ...
DETECTING INJECTION
                           FLAWS LOCALLY



Saturday, May 23, 2009
AVAILABLE TECHNIQUES


         • Static        code analysis

              • Examines       the source code

         • ...
STATIC CODE ANALYSIS

    • Manual              code review.

    • Static             code analyzers:

         • Pixy   ...
WHAT STATIC ANALYSIS CAN
              DETECT
    • Input              sanitization

         • Really          only boole...
DYNAMIC CODE ANALYSIS

    • The           only way to consider application state.

         • Remember              that ...
DEFENDING AGAINST XSS




Saturday, May 23, 2009
THERE ARE THREE CONTROL
            POINTS FOR XSS

                                             Web
                     ...
THE BROWSER

    • Different          browsers will execute different code snippets.

         • O9, IE6: <BODY BACKGROUND...
IT INFRASTRUCTURE

    • Web                application firewalls.

    • Intrusion              prevention systems.

    •...
WEB APPLICATION DEFENSE




Saturday, May 23, 2009
IT’S ALL ABOUT PROCESS
                         Request                           Return




                             ...
DECODE YOUR INPUT
                         Accept-Language: en-us,en;q=0.5
                         Accept-Charset: ISO-88...
SECURITY CHECKS

    • This          is where you apply your whitelists.

    • Remember       the principal of least priv...
SANITIZING HTML


    • There              are a number of libraries available to do this for you.

         • Microsoft A...
WRITING YOUR OWN
                         SANITIZATION LIBRARY
    •   Whitelist HTML tags.

         •   Be as restrictiv...
ENCODE YOUR OUTPUT


    • Most               commonly, encode using html entities.

    • After              entity encod...
EXPLICITLY DECLARE YOUR
                 CHARACTER SET

    • Your           web server can do it for you:
         •   Ad...
DO YOUR SECURITY CHECKS
            ACTUALLY WORK?
    foreach ($_GET as $secvalue) {
        if ((eregi(quot;<[^>]*script...
TESTING ARCHITECTURAL
           PATTERN IMPLEMENTATION



Saturday, May 23, 2009
VALIDATES INPUT
                                 SANITIZATION
                         Web Fuzzer                attack st...
VALIDATES OUTPUT
                             ENCODING

                  Endcoding Validator             attack strings  ...
[DEMO]




Saturday, May 23, 2009
TOOL BENEFITS

    • Finds              fundamental problems in software design

         • More    complex attacks rely o...
TOOL LIMITATIONS


    • Only               works with database-resident state data

         • Cookies, header, etc      ...
TOOL PLANS

    • Move               it from PHP to C#.

    • Create              a PM-friendly interface so that anyone ...
WHY IS THIS HARD?
             • Legacy  applications and languages often don’t lend
                 themselves to this a...
CALL TO ACTION


    • Write              better code.

    • Use           current browser technology.

    • Honestly   ...
I’M WEB 2.0


    • Blog: http://hackerco.de

    • LinkedIn: http://www.linkedin.com/pub/don-ankney/6/213/651

    • Twit...
BIBLIOGRAPHY

    •   Alshanetsky, Ilia. Php|Architect's Guide to Php Security|. Marco Tabini &
        Associates, Inc, 2...
BIBLIOGRAPHY
    •   Johns, M., Engelmann, B., and Posegga, J. “Xssds: Server-Side Detection of Cross-
        Site Script...
QUESTIONS?




Saturday, May 23, 2009
Upcoming SlideShare
Loading in...5
×

Is XSS Solvable?

1,207

Published on

Slides from my LayerOne 2009 presentation on cross site scripting.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,207
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
79
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Is XSS Solvable?"

  1. 1. IS XSS SOLVABLE? Don Ankney • LayerOne 2009 Saturday, May 23, 2009
  2. 2. DISCLAIMER This presentation represents personal work and has not been approved or vetted by Microsoft. I am solely responsible for its content. Saturday, May 23, 2009
  3. 3. OUTLINE • XSS as a generic injection attack. • What makes XSS unique, why it’s important. • Defending against XSS in general. • Web Application Defense • One effective architecture design pattern. • Tool to help. • Where to go from here. Saturday, May 23, 2009
  4. 4. DEFINING THE PROBLEM Saturday, May 23, 2009
  5. 5. INJECTION FLAWS • Any interpreted code can be injected: LDAP, XML, HTTP, XAML, PHP, Python, Ruby, and most infamously, SQL. • XSS is simply another form of interpreter injection, usually using Javascript. • We can 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. 6. PREVENTING INJECTION • Always keep track of your trust boundaries. • Validate/sanitize your inputs. • Properly encode your outputs. • Use white lists, not black lists. • Exercise the principal of least privilege. • Validate your assumptions. Saturday, May 23, 2009
  7. 7. TRUST BOUNDARIES User System Forms Files headers services cookies Processes ajax files Application Database SQL LDAP web data stores Saturday, May 23, 2009
  8. 8. WHY XSS IS DIFFERENT • Most injection flaws attack your server. • XSS attacks the end user -- it runs arbitrary code in their browser. • The browser is behind your firewall and is acting within the user’s security context. Saturday, May 23, 2009
  9. 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. 10. XSS TAXONOMY Saturday, May 23, 2009
  11. 11. REFLECTED XSS Attack Victim Attacker Attack Web App URL string Browser XSS • Victim browser submits an “evil” request that contains javascript. • The web application then reflects that javascript back to the victim browser, which then executes it. Saturday, May 23, 2009
  12. 12. REFLECTED XSS • Attack does not persist across users, sessions, or pages. • It is only reflected back to the user that submits the malicious url. • This is relatively easy to detect remotely via a scanner/fuzzer. Saturday, May 23, 2009
  13. 13. PERSISTENT XSS Attack string Attacker Webpage Database Victim Webpage XSS • An attacker stores an attack string in a web application. • Visitors to that site access infected pages causing javascript execution. Saturday, May 23, 2009
  14. 14. PERSISTENT XSS • Can persist across user, sessions, and pages. • It depends on application context and who can access the infected pages. • Very difficult to detect remotely via scanning/fuzzing. • There are many paths through an application, scanning is too noisy for a production system. • Best identified by code analysis. Saturday, May 23, 2009
  15. 15. HYBRID XSS Attack Webpage Attack A Attack Victim Attacker Session Data URL Browser XSS 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. 16. HYBRID XSS • Attacks are not persistent across sessions. • Attacks do persist across pages. • Attacks may persist across users. • Think about “who’s online” functionality. • Extremely difficult to detect remotely. • May require specific request sequences. Saturday, May 23, 2009
  17. 17. DETECTING INJECTION FLAWS REMOTELY Saturday, May 23, 2009
  18. 18. SCANNING FOR REFLECTED XSS VULNERABILITIES • This requires a simple fuzzer. • Send an attack string. • Check for appropriately encoded returns. • The most difficult part is maintaining a current attack string list. Saturday, May 23, 2009
  19. 19. SCANNING FOR PERSISTENT XSS VULNERABILITIES • This sort of scanner is immature. • Requires mapping input cause vs. output effect without knowledge of application state. •A persistent XSS scan is extremely noisy. • Each form has to have unique data submitted in order to map persistent data across the site. • Running an attack list against the mapped site creates one persistent record per attack string. Saturday, May 23, 2009
  20. 20. DETECTING INJECTION FLAWS LOCALLY Saturday, May 23, 2009
  21. 21. AVAILABLE TECHNIQUES • Static code analysis • Examines the source code • Dynamic analysis • Examines application state Saturday, May 23, 2009
  22. 22. STATIC CODE ANALYSIS • Manual code review. • Static code analyzers: • Pixy (PHP) • CAT.NET (ASP.NET) • CodeSecure (Java/ASP.NET/PHP) Saturday, May 23, 2009
  23. 23. WHAT STATIC ANALYSIS CAN DETECT • Input sanitization • Really only boolean, doesn’t evaluate quality. • Output encoding • Are both application (html) and character encoding explicit? • Data flow • Does anything skip sanitization or encoding? Saturday, May 23, 2009
  24. 24. DYNAMIC CODE ANALYSIS • The only way to consider application state. • Remember that persistent and hybrid XSS are state- dependent. • Internal representation of data is tied to risk. • There aren’t a lot of existing tools. • Most existing are run-time IPS-style tools. Saturday, May 23, 2009
  25. 25. DEFENDING AGAINST XSS Saturday, May 23, 2009
  26. 26. THERE ARE THREE CONTROL POINTS FOR XSS Web Browser Application Database IT Infrastructure XSS can be mitigated at all three points. Saturday, May 23, 2009
  27. 27. THE BROWSER • Different browsers will execute different code snippets. • O9, IE6: <BODY BACKGROUND=quot;javascript:alert('XSS');quot;> • FF2, O9: <META HTTP-EQUIV=quot;refreshquot; CONTENT=quot;0;url=data:text/ html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4Kquot;> • Current browsers are much better than previous generations. Saturday, May 23, 2009
  28. 28. IT INFRASTRUCTURE • Web application firewalls. • Intrusion prevention systems. • Web application sandboxes. • All of these are signature-based defenses. Saturday, May 23, 2009
  29. 29. WEB APPLICATION DEFENSE Saturday, May 23, 2009
  30. 30. IT’S ALL ABOUT PROCESS Request Return Security Decode Logic Encode Checks • This requires a consistent and enforced architectural approach. • JSP, PHP 3/4, and classic ASP don’t lend themselves to this approach. Saturday, May 23, 2009
  31. 31. DECODE YOUR INPUT Accept-Language: en-us,en;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 • If the request specified an encoding, you might want to assume that encoding for parameters. • HTTP defaults to ISO-8859-1 • Convert the request to your application’s internal representation. Saturday, May 23, 2009
  32. 32. SECURITY CHECKS • This is where you apply your whitelists. • Remember the principal of least privilege and use the most restrictive patterns possible. • If you must accept markup tags, parse the tags and replace them with tokens. • Consider whitelisting any paths or URLs. Saturday, May 23, 2009
  33. 33. SANITIZING HTML • There are a number of libraries available to do this for you. • Microsoft AntiXSS (.NET), • OWASP AntiSamy (Java, .NET, Python). • HTML Purifier (PHP) Saturday, May 23, 2009
  34. 34. WRITING YOUR OWN SANITIZATION LIBRARY • Whitelist HTML tags. • Be as restrictive as possible. • If allowing high-risk tasks (such as <a> and <img>), consider whitelisting their 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 is constructed in your code and not passed from the user. Saturday, May 23, 2009
  35. 35. ENCODE YOUR OUTPUT • Most commonly, encode using html entities. • After entity encoding, replace your tokens with actual tags. • If the final output is not html, encode accordingly. • XML if outputting AJAX, XAML, etc. Saturday, May 23, 2009
  36. 36. EXPLICITLY DECLARE YOUR CHARACTER 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) • <%Response.charset=quot;utf-8quot;%> (ASP.NET) • print quot;Content-Type: text/html; charset=utf-8nnquot;; (Perl) Saturday, May 23, 2009
  37. 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;<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</ b><br><br>[ <a href=quot;javascript:history.go(-1)quot;><b>Go Back</b></a> ]quot;); } } foreach ($_POST as $secvalue) { if ((eregi(quot;<[^>]*script*quot;?[^>]*>quot;, $secvalue)) || (eregi(quot;<[^>]*style*quot;?[^>]*>quot;, $secvalue))) { die (quot;<center><img src=images/logo.gif><br><br><b>The html tags you attempted to use are not allowed</ b><br><br>[ <a href=quot;javascript:history.go(-1)quot;><b>Go Back</b></a> ]quot;); } } This is actual code in a popular CMS. Saturday, May 23, 2009
  38. 38. TESTING ARCHITECTURAL PATTERN IMPLEMENTATION Saturday, May 23, 2009
  39. 39. VALIDATES INPUT SANITIZATION Web Fuzzer attack strings Sanitization Validator attack strings Stored strings Target Database App Virtual Machine Saturday, May 23, 2009
  40. 40. VALIDATES OUTPUT ENCODING Endcoding Validator attack strings Database Fuzzer Stored strings attack strings Target Database App Virtual Machine Saturday, May 23, 2009
  41. 41. [DEMO] Saturday, May 23, 2009
  42. 42. TOOL BENEFITS • Finds fundamental problems in software design • More complex attacks rely on either sanitization or encoding to be broken. • Detects persistent XSS attack vectors. • In a dedicated VM, noise doesn’t matter. Saturday, May 23, 2009
  43. 43. TOOL LIMITATIONS • Only works with database-resident state data • Cookies, header, etc are also valid XSS threats. • Only works against HTML forms • Can be extended to include AJAX, headers, cookies, etc. Saturday, May 23, 2009
  44. 44. TOOL PLANS • Move it from PHP to C#. • Create a PM-friendly interface so that anyone can run it. • Add authentication integration: • Web forms, OpenID. • Expand it to include non-form fuzzing. Saturday, May 23, 2009
  45. 45. WHY IS THIS HARD? • Legacy applications and languages often don’t lend themselves to this architectural pattern. • Browser behavior is often unexpected and gibberish code can be executed. • Application complexity makes it difficult to predict state, just like a client application. • Applications and developers change over time. Saturday, May 23, 2009
  46. 46. CALL TO ACTION • Write better code. • Use current browser technology. • Honestly assess your enterprise. • Do you have lots of legacy code? Saturday, May 23, 2009
  47. 47. I’M WEB 2.0 • Blog: http://hackerco.de • LinkedIn: http://www.linkedin.com/pub/don-ankney/6/213/651 • Twitter: http://twitter.com/dankney • E-mail: dankney@hackerco.de Saturday, May 23, 2009
  48. 48. BIBLIOGRAPHY • Alshanetsky, Ilia. Php|Architect's Guide to Php Security|. Marco Tabini & Associates, Inc, 2005. • Ernst, M., Artzi, S., Kiezun, A., Dolby, J., Tip, F., and Dig, D. “Finding Bugs in Web Applications Using Dynamic Test Generation and Explicit State Model Checking.” dspace.mit.edu (2009): • Ernst, M., Kiezun, A., Guo, P. J., Jayaraman, K., and Ernst, M. D. “Automatic Creation of Sql Injection and Cross-Site Scripting Attacks.” dspace.mit.edu (2008): • Fogie, Seth, Jeremiah Grossman, Robert Hansen, Anton Rager, and Petko D. Petkov. Xss Attacks: Cross Site Scripting Exploits and Defense. Syngress, 2007. Saturday, May 23, 2009
  49. 49. BIBLIOGRAPHY • Johns, M., Engelmann, B., and Posegga, J. “Xssds: Server-Side Detection of Cross- Site Scripting Attacks.” Proceedings of the 2008 Annual Computer Security Applications Conference (2008): 335-44. • Stuttard, Dafydd, and Marcus Pinto. The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws. Wiley, 2007. • Vogt, P., Nentwich, F., Jovanovic, N., Kirda, E., Kruegel, C., and Vigna, G. “Cross-Site Scripting Prevention With Dynamic Data Tainting and Static Analysis.” Proceeding of the Network and Distributed System Security Symposium (NDSS’07) (2007): • Wassermann, G., and Su, Z. “Static Detection of Cross-Site Scripting Vulnerabilities.” Proceedings of the 30th international conference on Software engineering (2008): 171-80. Saturday, May 23, 2009
  50. 50. QUESTIONS? Saturday, May 23, 2009
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×