Why Web Security Is Fundamentally Broken

1,748 views
1,618 views

Published on

Most people are disturbed when they witness just how much of their personal information is accessible the very moment they visit a website. Then, if you give that [malicious] website just one mouse-click --- out goes even more personally identifiable data. We’re talking about full names, where you live, the town where you grew up and went to school, martial status, list of friends, sites you are logged-in to, the software you use complete with version numbers, and in some cases, your browser’s auto-complete data and history of other sites you’ve visited. All of this is performed using nothing but HTML and JavaScript. No need for memory corrupting exploits that escape the confines of the browser walls.

Through a demo-driven presentation, the audience will see first-hand how and why all these attacks are possible, even in the presence of browser silent updates and the latest security improvements such as sandboxes, anti-phishing protections, and the availability of Content Security Policy, X-Frame-Options, Origin, Strict Transport Security, SSL, etc. And just so everyone is crystal clear, firewalls don’t help and neither does anti-virus software. The reason why none of this works is that these web attacks take advantage of flaws in the way the Web was designed to work! Adding insult to injury most of the techniques on display are NOT technically “new,” and this talk will cleverly wire these issues together to make a point, and tell a story. It is the story of Why Web Security Is Fundamentally Broken.

Here’s the punchline: The only known ways to fix these issues adequately is to “break the Web” -- i.e. negatively impact the usability of a significant percentage of websites. Doing so directly conflicts with business interests of the current browser vendors who are looking to grow market share and advertising revenue. Their choice is simple, be less secure and more adopted, rather than secure and obscure. This is the Web security trade-off that’s being made for us.

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

No Downloads
Views
Total views
1,748
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
86
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Why Web Security Is Fundamentally Broken

  1. 1. Why Web Security IsFundamentally BrokenJeremiah GrossmanFounder & Chief Technology Officer © 2012 WhiteHat Security, Inc. 1
  2. 2. Jeremiah GrossmanØFounder & CTO of WhiteHat SecurityØInternational PresenterØTED AlumniØInfoWorld Top 25 CTOØCo-founder of the Web Application Security ConsortiumØCo-author: Cross-Site Scripting AttacksØFormer Yahoo! information security officerØBrazilian Jiu-Jitsu Black Belt 2
  3. 3. WhiteHat Security• Headquartered in Santa Clara, CA• WhiteHat Sentinel – SaaS end-to-end website risk management platform (static and dynamic)• Employees: 220+ Cool Vendor The FutureNow List 3
  4. 4. Web Security A website must be able to defend itself against aRule #1: hostile client [browser]. © 2010 WhiteHat Security, Inc. | Page
  5. 5. Web Security A website must be able to defend itself against aRule #1: hostile client [browser]. Challenging, but possible to follow. © 2010 WhiteHat Security, Inc. | Page
  6. 6. Web Security A browser must be able to defend itself against aRule #2: hostile website. © 2010 WhiteHat Security, Inc. | Page
  7. 7. Web Security A browser must be able to defend itself against aRule #2: hostile website. Impossible. © 2010 WhiteHat Security, Inc. | Page
  8. 8. © 2010 WhiteHat Security, Inc. | Page 6
  9. 9. Today’s browsers make availabe toevery website you visit:Passive access to your operating systeminformation, various system settings, browser type /version, installed add-ons & plug-ins, geographiclocation, websites currently logged-into, etc. © 2010 WhiteHat Security, Inc. | Page 6
  10. 10. Today’s browsers make availabe toevery website you visit:Passive access to your operating systeminformation, various system settings, browser type /version, installed add-ons & plug-ins, geographiclocation, websites currently logged-into, etc. Give a website just 1 mouse-click — Then it gets access to: Your name, where you live, where you’ve been, town you grew up in and went to school, martial status, photos, and in some cases, the browser’s auto- complete data and surfing history. © 2010 WhiteHat Security, Inc. | Page 6
  11. 11. Today’s browsers make availabe toevery website you visit:Passive access to your operating systeminformation, various system settings, browser type /version, installed add-ons & plug-ins, geographiclocation, websites currently logged-into, etc. Give a website just 1 mouse-click — Then it gets access to: Your name, where you live, where you’ve been, town you grew up in and went to school, martial status, photos, and in some cases, the browser’s auto- complete data and surfing history.All browsers also allow a[malicious] website to:Force your browser to send self-incriminating Webrequests, hack your Intranet, auto-XSS / CSRF youon any website, etc. © 2010 WhiteHat Security, Inc. | Page 6
  12. 12. The 2 Types of Browser Attacks 1) Attacks designed to escape the browser walls and infect the operating system with malware. (a.k.a. Drive-by-Downloads) Security: Sandboxing, silent and automatic updates, increased software security, anti-phishing & anti- malware warnings, etc. [Enabled by default] 2) Attacks that remain within the browser walls and compromise cloud-based data. XSS, CSRF, Clickjacking, etc. Security: SECURE Cookies, httpOnly, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options, Content Security Policy, EV-SSL, etc. [Opt-In by website, users can’t protect themselves] © 2010 WhiteHat Security, Inc. | Page
  13. 13. Browser InterrogationOperating System and Browser Type via User-Agent HeadersUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89Safari/537.1Language setting, ActiveX support, and the Referer.GET / HTTP/1.1Host: http://maliciouswebsite/User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89Safari/537.1Accept-Language:en-US,en;q=0.8<script>if (navigator.language) {! console.log(navigator.language);}</script> © 2010 WhiteHat Security, Inc. | Page 8
  14. 14. Browser Interrogation (cont.)ActiveX<script>if(typeof(window.ActiveXObject)=="undefined"){! console.log(“ActiveX Unavailable");} else {! console.log(“ActiveX Available");}</script>RefererGET / HTTP/1.1Host: http://maliciouswebsite/User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5)AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89Safari/537.1Referer:http://searchengine/search?q=keywords © 2010 WhiteHat Security, Inc. | Page 9
  15. 15. Browser Interrogation (cont.)Virtualization Detection via Screen Dimensions<script>var  dimensions  =  {320,  200  :  ,  320,  200  :  ,  320,  240  :  ,  640,  480  :  ,  800,  480  :  ,  768,  576  :  ,  854,  480  :  ,  1024,  600  :  ,  1152,  768  :  ,  800,  600  :  ,  1024,  768  :  ,  1280,  854  :  ,  1280,  960  :  ,  1280,  1024  :  ,  1280,  720  :  ,  1280,  768  :  ,  1366,  768  :  ,  1280,  800  :  ,  1440,  900  :  ,  1440,  960  :  ,  1400,  1050  :  ,  1600,  1200  :  ,  2048,  1536  :  ,  1680,  1050  :  1,  1920,  1080  :  ,  2048,  1080  :  ,  1920,  1200  :  ,  2560,  1600  :  ,  2560,  2048  :  };  var  wh  =  screen.width  +  ",  "  +  screen.height;  if  (dimensions[wh]  !=  undefined)  {   console.log(“Not  virtualized");}  else  {   console.log(“OperaUng  in  a  virtualized  environment");  }</script> © 2010 WhiteHat Security, Inc. | Page 10
  16. 16. Browser Interrogation (cont.)Identifying Installed Extensions and Add-Ons(CHROME)<script  src=”chrome-­‐extension://aknpkdffaafgjchaibgeecgmgeghloj/manifest.json  ”  onload=”extensionDetected()”>  (Firefox)<script>if  (typeof  uniquelyNamedObject  !=  undefined){      console.log  ("Add-­‐On  Present");}</script> © 2010 WhiteHat Security, Inc. | Page 11
  17. 17. © 2010 WhiteHat Security, Inc. | Page 12
  18. 18. Common use-case:<img src=”http://someotherwebsite/image.png”><img src=”http://someotherwebsite/image.png”onload=”successful()” onerror=”error()”>If the image file loaded correctly, the “successful” Javascript function executes.If some error occurred, obviously the “error” function executes. © 2010 WhiteHat Security, Inc. | Page 12
  19. 19. Common use-case: DEMO<img src=”http://someotherwebsite/image.png”><img src=”http://someotherwebsite/image.png”onload=”successful()” onerror=”error()”>If the image file loaded correctly, the “successful” Javascript function executes.If some error occurred, obviously the “error” function executes.Login-Detection (via CSRF):<img src=”http://someotherwebsite/loggedin.png”onload=”loggedIn()” onerror=”notLoggedIn()”>.If the user is logged-in, the image file loads successfully, which executes the“loggedIn.” If they’re not logged-in, “notLoggedIn” is executed. © 2010 WhiteHat Security, Inc. | Page 12
  20. 20. Authenticated Javascript/CSSEvent Handler<script src=”http://thirdparty/javascript.js”onload=”loggedin()” onerror=”notloggedin()”></script>Object Detection<script src=”http://thirdparty/javascript.js”> </script><script>if (typeof loggedInObject != undefined){ console.log ("Logged-In");}</script>CSS Object Detection<link rel="stylesheet" type="text/css" href="http://thirdparty/stylesheet.css" /> © 2010 WhiteHat Security, Inc. | Page 13
  21. 21. Authenticated IFRAMEsiframe.contentWindow.length<iframe id=”login” src=”http://thirdparty/profile/”></iframe><script>if (iframe.contentWindow.length > 0) { console.log ("Logged-In");}</script>XFO Detection<iframe id=”login” src=”http://thirdparty/profile/”></iframe> © 2010 WhiteHat Security, Inc. | Page 14
  22. 22. XFO Detection<iframe id=”login” src=”http://thirdparty/profile/”></iframe><script src=”http://ajax.googleapis.com/ajax/libs/dojo/1.7.2/dojo/dojo.js”></script><script>var urls = [http://www.wikipedia.org/,http://ha.ckers.org/, http://www.google.com/,http://www.facebook.com/,https://github.com/,http://daringfireball.net/,];function detect() { dojo.forEach(urls, function(url) { var iframe = dojo.create(“iframe”, { src: url, id: url }); dojo.attr(iframe, “style”, {display: ‘none’}); dojo.connect(iframe, “onload”, function() { dojo.destroy(iframe); }); dojo.place(iframe, dojo.body()); setTimeout(function () { var obj = dojo.byId(url); if (obj) { dojo.destroy(iframe); var entry = dojo.create(“li”, null, dojo.body()); entry.innerHTML = “Yes: ” + url; } else { var entry = dojo.create(“li”, null, dojo.body()); entry.innerHTML = “No: ” + url; } }, 3000); });} © 2010 WhiteHat Security, Inc. | Page 15
  23. 23. Deanonymize (via Clickjacking) © 2010 WhiteHat Security, Inc. | Page 16
  24. 24. Deanonymize (via Clickjacking)Click For More Dancing Cats © 2010 WhiteHat Security, Inc. | Page 16
  25. 25. Deanonymize (via Clickjacking)Click For More Dancing Cats "A mashup is a self-inflicted XSS attack." Douglas Crockford © 2010 WhiteHat Security, Inc. | Page 16
  26. 26. Deanonymize (via Clickjacking)Click For More Dancing Cats "A mashup is a self-inflicted XSS attack." Douglas Crockford http://mayscript.com/blog/david/clickjacking-attacks-unresolvedDEMO © 2010 WhiteHat Security, Inc. | Page 16
  27. 27. “Unless youve taken very particularprecautions, assume every website youvisit knows exactly who you are, whereyou’re from, etc.”Jeremiah Grossman © 2010 WhiteHat Security, Inc. | Page 17
  28. 28. Browser Intranet HackingCirca (2006)<iframe src=”http://192.168.1.1/” onload=”detection()”></iframe> © 2010 WhiteHat Security, Inc. | Page 18
  29. 29. Browser Intranet HackingCirca (2006) Intranet Wiki Printer JavaScript HTT Malware User New Web Firewall Server Bug IP Phone Tracking<iframe src=”http://192.168.1.1/” onload=”detection()”></iframe> © 2010 WhiteHat Security, Inc. | Page 18
  30. 30. © 2010 WhiteHat Security, Inc. | Page 19
  31. 31. DEMO © 2010 WhiteHat Security, Inc. | Page 19
  32. 32. Cross-Site Scripting (XSS)At least 55% of websites+ Browser Auto-Complete = pwnCross-Site Request Forgery (CSRF)At least 19% of websitesDNS Rebinding © 2010 WhiteHat Security, Inc. | Page 20
  33. 33. © 2010 WhiteHat Security, Inc. | Page 21
  34. 34. © 2010 WhiteHat Security, Inc. | Page 21
  35. 35. © 2010 WhiteHat Security, Inc. | Page 21
  36. 36. © 2010 WhiteHat Security, Inc. | Page 21
  37. 37. PossibleSolutions? © 2010 WhiteHat Security, Inc. | Page 22
  38. 38. © 2010 WhiteHat Security, Inc. | Page 23
  39. 39. Login-DetectionIdea: Do not send the Web visitors cookie data to off-domain destinations, destinations different from thehostname in the URL bar, along with the Web requests. © 2010 WhiteHat Security, Inc. | Page 23
  40. 40. Login-DetectionIdea: Do not send the Web visitors cookie data to off-domain destinations, destinations different from thehostname in the URL bar, along with the Web requests.Breaks the WebNot sending cookies off-domain would break websitesusing multiple hostnames to deliver authenticatedcontent. Breaks single-click Web widgets like Twitter“Follow,” Facebook “Like,” and Google “+1” buttons.Also breaks visitor tracking via Google Analytics,Coremetrics, etc. © 2010 WhiteHat Security, Inc. | Page 23
  41. 41. © 2010 WhiteHat Security, Inc. | Page 24
  42. 42. DeanonymizationIdea: Ban IFRAMEs entirely, or at least ban transparentIFRAMEs. Ideally, browser users should be able to “see”what they are really clicking on. © 2010 WhiteHat Security, Inc. | Page 24
  43. 43. DeanonymizationIdea: Ban IFRAMEs entirely, or at least ban transparentIFRAMEs. Ideally, browser users should be able to “see”what they are really clicking on.Breaks the WebMillions of websites current rely upon IFRAMEs, includingtransparent IFRAMEs, for essential functionality. Notableexamples are Facebook, Gmail, and Yahoo! Mail. © 2010 WhiteHat Security, Inc. | Page 24
  44. 44. © 2010 WhiteHat Security, Inc. | Page 25
  45. 45. Browser Intranet HackingIdea: Create a barrier in the browser between “public”and “private” networks by prohibit the inclusion ofRFC-1918 on non-RFC-1918 websites. © 2010 WhiteHat Security, Inc. | Page 25
  46. 46. Browser Intranet HackingIdea: Create a barrier in the browser between “public”and “private” networks by prohibit the inclusion ofRFC-1918 on non-RFC-1918 websites.Breaks the WebSome organizations actually do include intranet contenton public websites, for their employees, which does notviolate RFC specification. © 2010 WhiteHat Security, Inc. | Page 25
  47. 47. Browser Intranet HackingIdea: Create a barrier in the browser between “public”and “private” networks by prohibit the inclusion ofRFC-1918 on non-RFC-1918 websites.Breaks the WebSome organizations actually do include intranet contenton public websites, for their employees, which does notviolate RFC specification. Vulnerabilities are required by Web standards. © 2010 WhiteHat Security, Inc. | Page 25
  48. 48. bigger problemKNOWN “WONT-FIX” ISSUES © 2010 WhiteHat Security, Inc. | Page 26
  49. 49. Browser vendor’s choice is simple: Be less secure and more useradopted, or secure and obscure. Browser War =Trench Warfare © 2010 WhiteHat Security, Inc. | Page 27
  50. 50. “[N]obodys breaking the web,dude. Not now, not ever.”Dan Kaminsky to Jeremiah Grossman, December 21, 2010 Security: SECURE Cookies, httpOnly, X-Frame-Options, Strict-Transport- Security, X-Content-Type-Options, Content Security Policy, EV-SSL, etc. •Opt-In security, by website owners •Measurably low adoption rates •Do not allow for Web users to protect themselves © 2010 WhiteHat Security, Inc. | Page 28
  51. 51. © 2010 WhiteHat Security, Inc. | Page 29
  52. 52. Web browsers are NOT “safe.” Web browsers are NOT “secure.”Web browsers do NOT protect your “privacy.” © 2010 WhiteHat Security, Inc. | Page 29
  53. 53. Web browsers are NOT “safe.” Web browsers are NOT “secure.”Web browsers do NOT protect your “privacy.” © 2010 WhiteHat Security, Inc. | Page 29
  54. 54. What do we do now? © 2010 WhiteHat Security, Inc. | Page 30
  55. 55. 1) Status Quo2) .SECURE3) Break the Web... © 2010 WhiteHat Security, Inc. | Page 31
  56. 56. Mobile Apps “DesktopApps”Mini-browsers, where each Custom browsers’ designed tosite / app is isolated. No automatically launch to a websiteissues with Login Detection, and go no further.Denaonymization, etc. © 2010 WhiteHat Security, Inc. | Page 32
  57. 57. Thank You!“I Know...” serieshttp://blog.whitehatsec.com/introducing-the-i-know-series/Blog: http://blog.whitehatsec.com/Twitter: http://twitter.com/jeremiahgEmail: jeremiah@whitehatsec.com © 2012 WhiteHat Security, Inc. 33

×