CIS 6614 meeting -*- Outline -*- * Cross-site Scripting (XSS) Attacks and Defenses Based on notes by Suman Jana, which are based on slides by John Mitchell ------------------------------------------ Cross-site Scripting (XSS) Attack: - Injects malicious script into trusted context Attacker's goal: - Steal information from honest website ------------------------------------------ Q: What kind of threat is the attacker posing? Unauthorized information disclosure ** type 1 attacks (non-persistent) Based on chapter 2 of the book Michael Howard, David LeBlanc, and John Viega. 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them. McGraw-Hill, 2010. ISBN: 978-0-07-162676-7 ------------------------------------------ CROSS-SITE SCRIPTING (XSS), TYPE 1 Attack idea: 1. Design URL containing malicious script 2. Get user to click on that URL 3. Web server puts the script on web page that is rendered on the user's browser 4. The user's browser runs the malicious script In JSP: <%= request.getParameter("Name") %> In Ruby on Rails: <%= comment.body %> ------------------------------------------ Q: How do you get step 2 to work? social engineering Attackers will use a service like tinyurl.com or snurl.com to abbreviate the URL Q: Why doesn't the attacker run the script themselves? To steal from the user, they need to run it as the user To gain access to the user's browser's information (cookies, history) Q: What role does the web server play in this? It has to reflect/echo the malicious script back to the user's browser in a web page it is rendering. It should sanitize the input, but if it doesn't it enables the attack Q: What threats are served by this attack? Spoofing of the client's identity, due to the use of tainted input. *** example ------------------------------------------ EXAMPLE XSS ATTACK, PAYPAL (2006) 1. Attackers contacted users via email 2. Fooled them into accessing URL hosted on the legitimate PayPal website 3. Injected code redirected PayPal visitors to a page warning users their accounts had been compromised 4. Victims were redirected to a phishing site and prompted to enter sensitive financial data. ------------------------------------------ ** type 2, persistent xss attacks ------------------------------------------ STORED XSS ATTACKS (TYPE 2) Like type 1, but the malicious query is stored by the server 1. Send input containing malicious script to the server, which stores it 2. Get user to browse that web site 3. Web server puts the script on web page that is rendered on the user's browser 4. The browser runs the malicious script ------------------------------------------ Q: What kinds of web sites store user input and show it to others? Product reviews, feedback, newspaper comments, chats... Q: Is there social engineering necessary to make this work? No, users may always look at that website, and the stored script is part of what is always shown... *** example, stored images ------------------------------------------ STORED IMAGE ATTACK Can a JPEG contain HTML? Yes, if request for site.com/pic.jpg results in: HTTP/1.1 200 OK ... Content-Type: image/jpeg fooled ya Some browsers would render the HTML ------------------------------------------ Hopefully modern browsers don't do that now... but IE did Q: Consider a photo-sharing site that allows users to upload images, could this result in XSS attacks? *** example, PDF viewer feature ------------------------------------------ PDF VIEWER ATTACK Adobe PDF viewer (vers. 7.9 and earlier) - Viewer would execute JavaScript in URLs such as: http://path/to/pdf/ file.pdf#name=javascript:code_here - JavaScript executed in context of domain where PDF file is hosted Attack: 1. Find PDF file on website.com 2. Create URL with JavaScript http://website.com/path/to/ file.pdf#s=javascript:alert("xss"); 3. Get victim to click on link 4. Reader plugin would execute the JavaScript ------------------------------------------ Q: What could the JavaScript do? pretty much anything, and if the user has access to website.com, then trouble for them... Q: Could this affect your local computer? Yes, if you click on link to PDF on your own computer! file:///C:/Program%20Files/Adobe/ Acrobat%207.0/Resource/ ENUtxt.pdf#blah=javascript:alert("XSS"); ** response splitting ------------------------------------------ RESPONSE SPLITTING Puts malicous script in HTTP headers In Ruby on Rails: redirect_to(url) ------------------------------------------ Note: the script is NOT in the body (like XSS types 1 and 2) Q: What's the problem with the rails code? If url isn't trusted, could be an attack. ** Summary of XSS attacks Q: What mistake is made by the developers that premits XSS attacks? trusting user input (and not checking the input for validity) and then putting that input in a browser Q: What can be done to prevent the attack? Validating input, sanitizing it (and not extracting user input in HTML format) Q: What kind of tool could catch the bad code involved? Taint checking or information flow checking ** mitigation of XSS attacks ------------------------------------------ MITIGATING XSS ATTACKS What can be done to stop XSS attacks? ------------------------------------------ ... - Don't trust/render user inputs: (this is basically an injection attack) - Use a positive allow list, - Validate inputs (or sanitize them) - Don't allow scripts to be rendered *** use caution in filtering ------------------------------------------ CAUTION: SCRIPTS NOT ONLY IN /* API response */ alert(document.domain); ------------------------------------------ Q: Can an attacker use a JSONP interface to execute arbitrary JavaScript? yes, by using an attacker-controlled callback (the callback is injected into the page) So, if the attacker knows what the response will be (or can control it) they can execute arbitrary code! See M. Zalewski. The subtle/deadly problem with CSP. 2011. http://goo.gl/sK4w7q Another technique is SOME, see: B. Hayak. Same origin method execution (some): Exploiting a callback for same origin policy bypass, 2014. (how is this like return-oriented programming?) ------------------------------------------ REFLECTION What does this JavaScript do? var array = document .getElementById('cmd') .value.split(','); window[array[0]] .apply(this, array.slice(1)); Is it dangereous if the attacker controls the value of cmd? ------------------------------------------ ... executes window.* functions with arbitrary arguments via markup such as: ... yes! Then can dynamically lookup and invoke a global function ------------------------------------------ DYNAMIC CODE FROM ANGULAR.JS What does this script do?

Is it dangerous if such a script gets data from the DOM? Does Angular use eval()? Angular also has a CSP-compatability mode (ng-csp) that interprets scripts for itself Can that mode bypass CSP restrictions? Does the app need to use Angular to be attacked? ------------------------------------------ ... it creates a template with arguments evaluated at user's site, then parses and executes it! ... Yes, because if the attacker controls part of the DOM's data then the attacker can execute aribtary computations Q: Does angular use eval()? Yes, which could bypass CSP restrictions Q: Can Angular's CSP-compatability mode bypass CSP restrictions? Yes, it's designed to do that! Q: Does the app need to use Angular to be attacked? No, it only has to whitelist a source that uses Angular (then it can inject a load of Angular, and then execute arbitrary computations!) ------------------------------------------ DATA OFTEN INTERPRETED AS JAVASCRIPT Web browsers interpret JavaScript everywhere: CSV data: Name,Value alert(1),234 Error messages that echo arguments: Error: alert(1)// not found. User file uploads ------------------------------------------ Q: When would a user file upload cause trouble? if it gets rendered on the web page, then executed! Q: Do these problems affect an app if a trusted source of scripts has such problems? Yes! So all domains that include JSONP and Angular are problems! ***** Path restriction policies ------------------------------------------ CSP2 ALLOWS PATHS IN A WHITELIST Content-Security-Policy: script-src example.org parially-trusted.org/foo/bar.js Does this respect privacy? Is this easy to maintain? So, CSP2 allows redirects Is allowing a redirect secure? ------------------------------------------ Q: Do paths in CSPs respect privacy? Not enough (since they are internal to a site) Q: Do paths in CSPs help or hurt maintenance? Hurts it source reorganizes files Q: Are redirects safe? No, if attacker can redirect anywhere, that bypasses policy! **** study results ------------------------------------------ RESULTS OF STUDY From Weichselbaum et al. (CCS'16), section 3 Data: all web pages ------------------------------------------ ***** How CSP is used in practice ------------------------------------------ USE IN PRACTICE Only 3.7% of web pages had a CSP Policies that can be bypassed: - using unsafe-inline - missing object-src - use of wildcards in whitelists - unsafe origin in whitelist contains JSONP or angular.js In practice use of: unsafe-inline 87.26% unsafe-eval 81.65% wildcards about 70% unsafe origins about 50% ------------------------------------------ Q: What do these data tell us? That more strict CSP policies are too restrictive in practice And what is the main problem? The whitelists! **** improvements to CSP ------------------------------------------ IMPROVEMENTS PROPOSAL In the Weichselbaum et al. (CCS'16) paper section 4 - Don't rely on whitelists - Use nonces, from inline (static) sources Content-Security-Policy: script-src 'nonce-random123' default-src 'none' ------------------------------------------ Q: What is a nonce? a code/key that is random, so hard to guess Q: How does that help? Only the called script would have the nonce so scripts are "whitelisted individually" (p. 1384) Dynamically injected scripts wouldn't have the right nonce ------------------------------------------ HOW TO ALLOW DYNAMIC SCRIPTS? JavaScript libraries often use dynamically created scripts How can these scripts get the right nonce? With script-src script-dynamic - nonce inherited by scripts created by trusted scripts This works on several apps e.g., Google Maps ------------------------------------------ Q: How can dynamically created scripts get the right nonce? **** evaluation ------------------------------------------ LIMITATIONS OF THE PROPOSAL Of the Weichselbaum et al. (CCS'16) paper - XSS can occur if attacker can inject URL used to dynamically create script - injections into scripts with nonces will allow unrestricted code ------------------------------------------ ------------------------------------------ COMPATABILITY Need to rewrite code that uses: - document.write() to add scripts instead: - pass nonce, or - use createElement() - inline event handlers - URIs of the form javascript:... ------------------------------------------ So some rewriting still neeed **** Summary ------------------------------------------ SUMMARY Of the Weichselbaum et al. (CCS'16) paper - CSP is insecure in practice due to whitelists - nonce-based CSP would be better ------------------------------------------