Be Afraid. Be Very Afraid. Javascript security, XSS & CSRF


Published on

See for more info.

A walk through real-world web site vulnerabilities - Mark shows step by step how vulnerable web sites can be exploited to trigger annoying pop up windows to more sinister attacks involving session stealing and rewriting page content. Learn how to test for and protect against these increasingly common attacks.


Published in: Technology
1 Comment
  • Great presentation, thank you! The audio of the presentation was especially nice to go with the sides... Would you be willing to enable downloads of the slides by any chance?
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Be Afraid. Be Very Afraid. Javascript security, XSS & CSRF

  1. 1. Be Afraid, Be Very Afraid JavaScript Security, XSS, CSRF and Clickjacking Mark Stanton - Gruden
  2. 2. Definitions •  XSS – Cross Site Scripting •  CSRF – Cross Site Request Forgery
  3. 3. Cross Site Scripting
  4. 4. Cross Site Scripting: MySpace How Samy became very popular Samy’s script made everyone who viewed his profile: •  Add him as a friend •  Embed the script in their profiles
  5. 5. Cross Site Scripting: MySpace
  6. 6. Cross Site Scripting: MySpace
  7. 7. Cross Site Scripting: MySpace
  8. 8. Cross Site Scripting: MySpace
  9. 9. Cross Site Scripting: MySpace
  10. 10. Cross Site Scripting: MySpace How did it work? <div id=quot;mycodequot; style=quot;background:url('java script:eval(document.all.mycode.expr)')quot; expr=quot;...lots of JS here...quot; > •  JS inside CSS URL •  Line break in the word “javascript” •  Evaluation of a expression
  11. 11. Cross Site Scripting What is Cross Site Scripting? •  Untrusted data enters the system –  URL, Form or Cookie data –  HTTP Header –  Syndicated feed –  other offline system •  Data then presented to the user & executed in their browser •  Interferes with the intended interaction between a user and a site
  12. 12. Cross Site Scripting How is it possible? •  Browser environment is insecure by design –  Multiple contexts, multiple parsers –  XML, HTML, CSS, JavaScript, DOM, Cookie, URI, VBScript –  All interacting in semi-structured ways •  This makes AJAX and Web 2.0 Mash ups so powerful
  13. 13. Cross Site Scripting Context Switching •  HTML to JS <script>alert(‘XSS’)</script> <body onload=alert(‘XSS’)> •  URL to JS <iframe src=javascript:alert(‘XSS’)> •  CSS to JS background:url(javascript:alert(‘XSS’))
  14. 14. Cross Site Scripting Same-origin Policy •  Prevents document from one site setting or getting properties of a document from another •  Same origin means same protocol, port and host •  So if I frame another site - I can’t modify or read it
  15. 15. Cross Site Scripting But... •  Included JS runs in the context of the current page •  Scripts running in the page context have “root” access to a site
  16. 16. Cross Site Scripting What can happen if an attacker gets a script on your page? •  Perform action against website as if they are the user •  Read the contents of pages and cookies •  Control the display & show fake content to user •  Send information to any server in the world •  Request additional scripts from anywhere
  17. 17. Cross Site Scripting What can happen if an attacker gets a script on your page? •  SSL is no protection •  Logins are no protection
  18. 18. Cross Site Scripting: Demo
  19. 19. Cross Site Scripting: Demo
  20. 20. Cross Site Scripting: Demo
  21. 21. Cross Site Scripting: Demo
  22. 22. Cross Site Scripting: Demo
  23. 23. Cross Site Scripting: Demo
  24. 24. Cross Site Scripting: Demo
  25. 25. Cross Site Scripting: Demo
  26. 26. Cross Site Scripting: Demo
  27. 27. Cross Site Scripting: Demo
  28. 28. Cross Site Scripting: Demo
  29. 29. Cross Site Scripting: Demo
  30. 30. Cross Site Scripting: Demo
  31. 31. Cross Site Scripting: Demo
  32. 32. Cross Site Scripting: Demo
  33. 33. Cross Site Scripting: Demo
  34. 34. Cross Site Scripting: Demo What happened? •  Cookies stolen •  Interface vandalised •  Users prompted to download malware •  DB poisoned - other users affected
  35. 35. Cross Site Request Forgery
  36. 36. Cross Site Request Forgery: GMail GMail vulnerability used to steal a domain •  Visits evil site while logged into GMail •  Evil site POSTs to GMail creating a new filter •  Filter forwards all mail to attacker and deletes mail •  Attacker initiates domain transfer process
  37. 37. Cross Site Request Forgery Session riding •  Uses persistent sessions to execute actions against a service •  Many Web 2.0 services are vulnerable
  38. 38. Clickjacking
  39. 39. Clickjacking UI Redressing •  User is tricked into inadvertent actions –  A dummy button is shown, then target page is loaded over the top in a transparent iframe –  User thinks they are clicking the dummy button, but are interacting with a site they can’t see
  40. 40. Clickjacking: Twitter Don’t Click •  Mischievous page loads transparent iframe containing Twitter post •  User shown a button saying “Don’t Click” •  Click takes place in iframe and results in tweet being sent •  Grows exponentially •  Twitter implements frame buster
  41. 41. Solutions
  42. 42. Solutions Sanitise Input •  Whitelists –  Allow <strong>, <em> and <br> only –  Does help, but not 100% •  Blacklists –  Block <script> and friends –  Extremely common attack vector –  Extremely difficult to block most attacks –  Coldfusion’s XSS protection = FAIL!
  43. 43. Solutions Escape Output •  HTML Entity Encoding - HTMLEditFormat() •  Doesn’t always work –  In <script> –  In onmouseover= –  In CSS –  In URLs •  Need to be aware of your context
  44. 44. Solutions The OWASP ESAPI •  5 Rules for escaping output #1 - HTML Escape before inserting into element content #2 - Attribute Escape before inserting into attributes #3 - JavaScript Escape before inserting into JavaScript data values #4 - CSS Escape before inserting into style property values #5 - URL Escape before inserting into URL attributes •  Java API that implements these rules •  100% safe?
  45. 45. Solutions The OWASP ESAPI <cfset ESAPI = createObject('Java','org.owasp.esapi.ESAPI')> <cfsavecontent variable=quot;evilStringquot;> <div id=quot;mycodequot; style=quot;background:url('java script:eval(document.all.mycode.expr)')quot; expr=quot;alert('XSSed')quot;> </cfsavecontent> <cfoutput> #evilString# #ESAPI.encoder().encodeForHTML(evilString)# #ESAPI.encoder().encodeForHTMLAttribute(evilString)# #ESAPI.encoder().encodeForCSS(evilString)# #ESAPI.encoder().encodeForJavascript(evilString)# #ESAPI.encoder().encodeForURL(evilString)# </cfoutput>
  46. 46. Solutions Minimise Attack Surface •  Don’t allow GET to modify data •  Strict server-side validation of all input •  Check referrer •  Use transaction tokens or “crumbs” - derived from timestamp & user id •  Double submit cookies •  Use frame busting scripts •  Short session timeouts / in-memory cookies
  47. 47. Solutions Design for a breach •  Assume some portion of your users’ accounts will be hijacked at some point •  What if a users email account is hacked? •  Forgotten password functions should use secret question •  Two factor authentication where appropriate •  Can you rollback or recover? •  Do you have an audit trail?
  48. 48. Solutions Think very carefully about 3rd party scripts •  Google Analytics •  Hosted Libraries •  Digg •  AddThis Would you give Telstra the keys to your house? What about your cleaner?
  49. 49. Solutions Must allow untrusted 3rd party JavaScript? Use safe sub-sets: •  Adsafe •  Caja
  50. 50. Solutions Browsers are getting better •  Many exploits depend on bugs in browser parsers •  Holes are being rapidly closed •  IE6 is still horribly broken and has market share
  51. 51. Using Flash and PDF? They each have their own issues to consider •  Certain version of the Acrobat Reader have serious vulnerabilities http://path/to/pdf/file.pdf#foo=javascript:code_here •  Flash is also some potential weak points: <cross-domain-policy> <allow-access-from domain=quot;*quot;/> </cross-domain-policy>
  52. 52. Conclusion •  A lot of responsibility lies with developers •  Use a holistic, multi-pronged approach
  53. 53. Thanks Links • • • Thanks to pierre_tourigny (