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

Be Afraid, Be Very Afraid JavaScript Security, XSS, CSRF and Clickjacking Mark Stanton - Gruden

Definitions •  XSS – Cross Site Scripting •  CSRF – Cross Site Request Forgery

Cross Site Scripting

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

Cross Site Scripting: MySpace

Cross Site Scripting: MySpace How did it work? <div id=\"mycode\" style=\"background:url('java script:eval(document.all.mycode.expr)')\" expr=\"...lots of JS here...\" > •  JS inside CSS URL •  Line break in the word “javascript” •  Evaluation of a expression

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

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

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’))

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

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

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

Cross Site Scripting What can happen if an attacker gets a script on your page? •  SSL is no protection •  Logins are no protection

Cross Site Scripting: Demo

Cross Site Scripting: Demo What happened? •  Cookies stolen •  Interface vandalised •  Users prompted to download malware •  DB poisoned - other users affected

Cross Site Request Forgery

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

Cross Site Request Forgery Session riding •  Uses persistent sessions to execute actions against a service •  Many Web 2.0 services are vulnerable

Clickjacking

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

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

Solutions

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!

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

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?

Solutions The OWASP ESAPI <cfset ESAPI = createObject('Java','org.owasp.esapi.ESAPI')> <cfsavecontent variable=\"evilString\"> <div id=\"mycode\" style=\"background:url('java script:eval(document.all.mycode.expr)')\" expr=\"alert('XSSed')\"> </cfsavecontent> <cfoutput> #evilString# #ESAPI.encoder().encodeForHTML(evilString)# #ESAPI.encoder().encodeForHTMLAttribute(evilString)# #ESAPI.encoder().encodeForCSS(evilString)# #ESAPI.encoder().encodeForJavascript(evilString)# #ESAPI.encoder().encodeForURL(evilString)# </cfoutput>

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

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?

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?

Solutions Must allow untrusted 3rd party JavaScript? Use safe sub-sets: •  Adsafe •  Caja

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

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=\"*\"/> </cross-domain-policy>

Conclusion •  A lot of responsibility lies with developers •  Use a holistic, multi-pronged approach

Thanks Links •  http://blog.gruden.com/category/js-security •  http://delicious.com/markstanton/js-security •  http://twitter.com/MarkStanto Thanks to pierre_tourigny (http://www.flickr.com/photos/pierre_tourigny/367078204/)