Automatic and Precise Client-Side Protection against CSRF Attacks Philippe De Ryck, Lieven Desmet, Wouter Joosen, Frank Piessens Philippe.DeRyck@cs.kuleuven.be

Outline Cross-site Request Forgery (CSRF) Client-side Protection against CSRF Client-Side Request Filtering Request Filtering Policy Formal Evaluation Practical Evaluation Conclusion 13/11/2018

Cross-Site Request Forgery 13/11/2018

Cross-site Request Forgery Cross-site Request Forgery can be used to … take over your blog modify your YouTube account obtain your email address steal your money W. Zeller and E. Felten, Cross-site Request Forgeries: Exploitation and Prevention, Technical Report, October 2008 13/11/2018

Normal surfing scenario Open “My Insecure Bank” (GET www.mib.com) User (Browser) Web Server www.mib.com Some welcome page Login to the bank (POST www.mib.com/auth, user=Philippe, pass=bleh) Login successful (Set cookie) Execute wire transfer (POST www.mib.com/wt, to=000-0000001-01, amount=100) Wire transfer executed 13/11/2018

CSRF Attack Scenario Web Server www.mib.com Already authenticated with “My Insecure Bank” User (Browser) Execute wire transfer (POST www.mib.com/wt, to=000-0000001-01, amount=100) Wire transfer executed Web Server lolcats.com Browsing for LOLcats (GET lolcats.com/top10) Page of LOLcats with an embedded CSRF attack Continue “being productive” More LOLcats 13/11/2018

CSRF Payload <iframe id=“frame” style=“width=0px;height=0px;border=0px”></iframe> <script> var html = “”; html+ = “<form id=‘form’ method=‘post’ action=‘http://www.mib.com/wt’>”; html += “<input type=‘hidden’ name=‘to’ value=‘000-0000001-01’>”; html += “<input type=‘hidden’ name=‘amount’ value=‘99999’>”; html += “</form>”; document.getElementById(“frame”).contentDocument.body.innerHTML = html; document.getElementById(“form”).submit(); </script> 13/11/2018

Client-Side Protection against CSRF 13/11/2018

Client-Side Countermeasures (1) Several browser add-ons available Collect information from browser Make a decision for each request Mitigation: blocking or stripping request Examples: NoScript ABE Request Policy CsFire 13/11/2018

Client-Side Countermeasures (2) Current client-side countermeasures Affect each cross-origin request Very secure Negative impact on usability Experience from CsFire (33,000+ downloads) Limited impact on usability A few cross-origin scenarios break Currently addressed by central/local policies 13/11/2018

Cross-Origin Scenarios Examples: Payment Providers, Single sign-on Hard to distinguish Often look like CSRF attacks Intention of user/site is unknown Current status Broken by all client-side countermeasures Can be addressed using specific policy rules 13/11/2018

Cross-Origin Scenario – Payment 13/11/2018

Cross-Origin Scenario – SSO 13/11/2018

State of Client-Side Countermeasures CSRF Payment SSO NoScript ABE RequestPolicy CsFire < 1.0 13/11/2018

Client-side Request Filtering 13/11/2018

Idea behind the Client-side Policy Site A can delegate control to site B E.g. when B is a payment provider When B is finished, control is transferred back to A E.g. when the payment is complete and A needs to complete the transaction Detect delegation to B and allow B to return to A 13/11/2018

Idea behind the Client-side Policy (2) Strip all cross-origin requests unless it is an expected request A request from B to A is expected if A previously delegated to B Delegation from A to B occurs if A issues a POST request to B or if A redirects to B using a parametrized URI 13/11/2018

Delegation Illustrated Cross-Origin Parametrized Redirect Cross-Origin POST 13/11/2018

Assumption of Delegation Can an attacker delegate control? POST request By form submission or using XHR Requires script injection (which trumps CSRF) Parametrized Redirect By injecting server-side code (total compromise) Using an open redirect (direct attack possible, so no point in using a delegation and expected request) Limit expected requests to single GET 13/11/2018

State from Previous Request Client-side Policy State from Previous Request Redirect? no yes yes sameOrigin(ctx,dst) sameOrigin(last,dst) no no Expected? yes yes no State from Origin No State 13/11/2018

Cross-Origin Scenario – Payment 13/11/2018

Cross-Origin Scenario – SSO 13/11/2018

Cross-Origin Scenario – Attacks 13/11/2018

Formal Evaluation Formal model of policy Analysis results First for client-side CSRF countermeasure Gives strong security guarantees Base model by Akhawe et al. [1] Analysis results Bounded scope: 9 HTTP events, 4 origins, … No CSRF scenarios found Functional scenarios are possible [1] Devdatta Akhawe, Adam Barth, Peifung E. Lam, John Mitchell, and Dawn Song. Towards a formal foundation of web security. Computer Security Foundations. Symposium, IEEE, 0:290–304, 2010. 13/11/2018

Practical Evaluation Implementation as extension of CsFire Tested against benchmark of CSRF scenarios Different attack vectors: HTML, CSS, JS, redirect, … Tested on real-life functional scenarios 13/11/2018

State of Client-Side Countermeasures CSRF Payment SSO NoScript ABE RequestPolicy CsFire < 1.0 CsFire >= 1.0 13/11/2018

Evaluating Delegation in Real-Life Traffic Only two cases with unverifiable delegation In Total: 0.0042% of origins Redirecting search engines (6.05 % of requests) URL shorteners (1.37 % of requests) Category % of requests Third Party Service Mashups 52.95% Multi-Origin Websites 25.27% Content Aggregators 14.97% URL Shorteners 1.37% False Positives 2.20% Others (unclassified) 3.24% Total number of delegations 100.00% 13/11/2018

Conclusion 13/11/2018

Conclusion Client-side CSRF countermeasure Delegation between sites Improved balance usability and security Support for cross-origin collaborations Formal evaluation of the policy Delegation between sites Experimentally evaluated Minor compromise on security 13/11/2018

CsFire – Mozilla Add-Ons 13/11/2018