Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

W3 conf hill-html5-security-realities

19,151 views

Published on

Slides for "HTML5 Security Realities" talk at W3Conf: Practical Standards for Web Professionals 2013.

Brad Hill - PayPal
@hillbrad

Published in: Technology
  • Great job Brad. We enjoyed the content.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Please dear can you contact me on my email id jessicaduale@yahoo.com, i have something private to discuss with you. Thank, i will be happy to meet you in my email. Jessica
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

W3 conf hill-html5-security-realities

  1. 1. HTML5 Security Realities Brad Hill, PayPal bhill@paypal-inc.com @hillbrad W3Conf: Practical standards for web professionals 21 -22 February 2013 San Francisco
  2. 2. “The reason that the Web browser isthe principal entry point formalware is the number of choicesthat a browser offers up towhomever is at the other end.Evolving technologies likeHTML5 promise to make thissignificantly worse.” – Dan Geer
  3. 3. In the next 30 minutes:• Show you real code using new standards to: – Solve Script Injection Vulnerabilities – Build Secure Mashups• HTML5 is a big step forward in security for the Web platform
  4. 4. Solving ScriptInjection
  5. 5. Script Injection, also known as Cross-SiteScripting or XSS, is the most common Web Application vulnerability.In 2007, WhiteHat estimated that 90% of sites were vulnerable.
  6. 6. XSS in a nutshell:If somebody else’s code gets torun in your WebApp, it’s not yourWebApp anymore.+ Same-Origin Policy = XSSanywhere on your domain is XSSeverywhere on your domain.
  7. 7. Current defenses: • Input filtering – Strip dangerous characters and tags from user data • Output encoding – Encode user data so it isn’t treated as markup“HTML5 broke my XSS filter!”
  8. 8. YES. html5sec.org lists a dozen new XSS vectors in new tags and attributes in HTML5.But your filter was already broken.
  9. 9. </a/style=-=a\b expr65ss/*&#x2a/ion(URL=javascript:%5cu0064ocum%5cu0064ocum%5cu0065nt.writ%5cu0065(1) )>
  10. 10. 1;--<?f><x:!μ!:x/style=`b\65h0061vior:url(#def&#x61ult#time2);`/onbegin=&#x5b�=u0061le&#114t&#40&#x31)&#x5d&#x2f/&#xy,z>
  11. 11. XSS Filters Were DoomedFilters are a server-side attempt to simulate theclient-side parser and execution environment.But…• Every browser parser operated differently• The algorithms were secret• Every browser had proprietary features, tags and syntax• Accepting bad markup was a feature
  12. 12. Generously coercing a shambling mound of line noise into anapplication is no longer a competitive feature.
  13. 13. By standardizing the technology for building Rich Web Applications,HTML5 began a fundamental shift inthe security posture of the Web as a platform.
  14. 14. Proprietary platforms compete for developers by offering features.Open platform implementerscompete for users by offering quality.
  15. 15. And now,BACK TO SOLVING SCRIPT INJECTION
  16. 16. New and Better Anti-XSS ApproachesEven if we now have some hope of simulatingthe browser parser for HTML5… Not easy, definitely not future-proof. Misses client-only data flows.Why not get help from the client?
  17. 17. Content Security Policy 25 6.0 6.0 6.0 10 X-Content-Security-Policy X-WebKit-CSP (sandbox only)HTTP header to enforce, in the client, a least- privilege environment for script and other content.
  18. 18. Content-Security-Policy:default-src self;object-src none;img-src https://uploads.example-board.net https://cdn.example-board.com data:;script-src https://code.example-board.net https://www.google-analytics.com;frame-src *.youtube.com;report-uri https://www.example-board.net/cspViolations.xyz
  19. 19. Content Security Policy 1.0default-src Everythingscript-src Scriptsobject-src Pluginsstyle-src CSSimg-src Imagesmedia-src Audio + Videoframe-src Frame contentfont-src Fontsconnect-src Script-loaded content (e.g. XHR)sandbox Same as HTML5 iframe sandboxreporturi Violation reporting
  20. 20. The catch…• CSP enforces code / data separation• This means: NO inline script or css NO eval, even in libraries(can be disabled, but sacrifices many of thebenefits of CSP)
  21. 21. <script> function doSomething ()…</script><button onClick="doSomething()">Click Here!</button>
  22. 22. <!--myPageScript.js-->function doSomething ()…Document.addEventListener(‘DOMContentLoader,function() { for var b indocument.querySelectorAll(.clickme‘))e.addEventListener(click, doSomething); });<!--myPageContent.html--><script src="myPageScript.js"></script><button class="clickme">Click Here!</button>
  23. 23. Coming soon in CSP 1.1• Whitelisting of inline scripts and CSS• More granular origins• Better control of plugins and media types• Control and reporting for reflected XSS filters• META tag supporthttps://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html
  24. 24. TemplatingTemplating is one of the oldest and most widelyused Web application construction patterns.But it is a hive of XSS villainy because it hasnever been a first-class feature in the client.
  25. 25. HTML TemplatesNew spec in progress in the WebApps WG: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.htmlDeclare templates as first-class client-sideobjects for increased performance, reduced XSSrisk.
  26. 26. With CSP and a careful applicationarchitecture XSS can be solved today.In the near future it will be possibleusing more familiar and betterperforming idioms.
  27. 27. Secure Mashups“HTML5 and CORS give newways to bypass the Same-OriginPolicy!”
  28. 28. A “mashup” incorporates content from multiple origins under different administrative control. Today, more apps than not areauthenticated mashups: ads, analytics, federated login How did we do this before HTML5?
  29. 29. Flash, with crossdomain.xml<?xml version="1.0"?><!--https://www.foo.com/crossdomain.xml--><cross-domain-policy> <allow-access-from domain=“www.example-analytics.com"/></cross-domain-policy>
  30. 30. Jan’s Rule:“Give someone an ACL, and they’ll put in a *.”
  31. 31. A “*” in your master crossdomain.xml policy means your users’ information is vulnerable to any malicious SWF, anywhere on the Web
  32. 32. I can’t use Flash on iOS anyway…What about HTML-only methods?
  33. 33. <script src=“foreignOrigin"> Same-Origin Loophole Browser example-2.com Origin=example.com <script src= https://example-2.com/x.js> (function( window, undefined ) {…example.com
  34. 34. AKA – “JSONP”• “JSON with padding”<script src=“example.com/jsonp?callback=foo”>• Returns JSON data “padded” with a call to the function you specified.• You hope…it’s still script!
  35. 35. This pattern injects somebody else’s code into your application.Remember what the definition of XSS was?
  36. 36. <scriptsrc="//connect.facebook.net/en_US/all.js"></script>
  37. 37. We canbuild it better. We have the technology.
  38. 38. Cross-Origin Resource Sharing (CORS) 22 5.1 3.2 15 15 2.1 10 7Voluntarily relax the Same-Origin Policy with anHTTP header to allow permissioned sharing on aresource-by-resource basisAccess-Control-Allow-Credentials: trueAccess-Control-Allow-Origin: someorigin.com
  39. 39. CORS Client Examplevar xhr = new XMLHttpRequest();xhr.open(method, xDomainUrl, true);xhr.withCredentials = true;xhr.onload = function() { var responseText = xhr.responseText; validatedResponse = validate(responseText); };xhr.onerror = function() { console.log(There was an error!); };xhr.send();
  40. 40. The difference:Script src gives you code youhave no choice but to TRUSTCORS gives you data you canVERIFY
  41. 41. What about the * in CORS? * cannot be used for a resource that supports credentials.* in Access-Control-Allow-Origin gives other originsonly the same view they already have from their ownserver. Access-Control-Allow-Origin: * is actually one of the safest ways to use CORS!
  42. 42. What if you need data from somebody who doesn’t publish a CORS API?
  43. 43. sandboxed iframes 23 5.1 4.2 15 2.1 10 7andpostMessage 23 5.1 4.2 16 12.1 2.1 8 7
  44. 44. trusted.mydomain.com/foo.html<iframe sandbox=“allow-scripts”src=“integration.mydomain.com/wrapLogin.html ”></iframe> By using a different domain name, many benefits of the sandbox can be achieved, even in browsers that don’t support it.
  45. 45. integration.mydomain.com/wrapLogin.html <html> <script src=“foreigndomain.com/login.js”> </script> <script> window.parent.postMessage(loginName, “trusted.mydomain.com”); </script> </html>
  46. 46. trusted.mydomain.com/foo.html<iframe sandbox=“allow-scripts”src=“untrusted.mydomain.com/untrusted.html”></iframe><script>window.addEventListener("message", receiveMessage, false);receiveMessage = function(event) { if(event.origin == “untrusted.mydomain.com”) { var data = sanitizeData(event.data);}<script>
  47. 47. But wait, there’s more!What if you do this to your own code?
  48. 48. http://www.cs.berkeley.edu/~devdatta /papers/LeastPrivileges.pdf
  49. 49. Hackers HATE Him!!!!Reduce your Trusted ComputingBase by 95% with this one simple HTML5 trick!!!
  50. 50. Summary: HTML5HTML5 and the Open Web Platform areimproving the security of the Web ecosystem.Rich Web Apps are not new, and HTML5 offersbig security improvements compared to theproprietary plugin technologies it’s actuallyreplacing.
  51. 51. Summary: Script Injection• Script Injection, aka XSS, can be a solved problem with proper application architecture and new client-side technologies.• Avoid incomplete server-side simulation, solve it directly in the client environment: – Content Security Policy – HTML Templates
  52. 52. Summary: Mashups• Use CORS to get (and validate) data, not code• Use iframes and postMessage to isolate legacy mashup APIs• Treat your own code like a mashup: Use the Same-Origin Policy as a powerful privilege separation technique for secure application architecture in HTML5https://github.com/devd/html5privsep
  53. 53. Ongoing work in WebAppSec WG:• Content Security Policy 1.1• User Interface Security to Kill Clickjacking• Sub-Resource Integrity• More important work underway in the Web Cryptography WG
  54. 54. public-webappsec-request@w3.orgThank you! Questions? Brad Hill, PayPal bhill@paypal-inc.com @hillbrad W3Conf: Practical standards for web professionals 21 -22 February 2013 San Francisco

×