1. 1 A Privacy-Preserving Defense Mechanism Against Request Forgery Attacks Ben S. Y. Fung and Patrick P. C. Lee The Chinese University of Hong Kong TrustCom’11

2. 2 Motivation  HTTP session state management is important in modern web applications State includes authentication credentials Clients insert state into HTTP requests Web servers use state to identify clients’ privileges  Examples of state: Cookies Authentication header Data embedded GET/PUT requests

3. 3 Motivation  HTTP session state management is subject to various security risks  One top risk: Cross-site request forgery (CSRF) An attacker triggers an HTTP request that carries session state of a client, without client’s knowledge OWASP Top 10 Application Security Risks in 2010

4. 4 How CSRF Works How CSRF Works  Root cause of CSRF Existing browsers do not check whether a client actually initiates an HTTP request Malicious Website Browser Target Website Send login request Send forged request with cookies Return login response with cookies Visit malicious website Return malicious code

5. 5 General Request Forgery  Variants of CSRF Login CSRF [Barth et al., 08] Trigger forged login requests without active sessions Clickjacking [Hansen and Grossman, 08] Put an invisible frame of target website on malicious website  Same site request forgery (SSRF) Target and malicious websites on same domain (origin) but maintained by different owners http://www.aaa.com/~alice http://www.aaa.com/~trudy Cross-origin checking no longer works

6. 6 Related Work  Header checking Checks origin header [Barth et al., CCS 08]. Can’t defend SSRF  Token validation Insert secure tokens in form [CSRFGuard, 10]. Token protected by same origin policy. Can’t defend SSRF.  Client-side defense e.g., BEAP [Mao et al., FC 09] Behavioral inference. Can generate high false alarms.

7. 7 Related Work  Fine-grained access control E.g., SOMA [Oda et al., CCS 08], Csfire [De Ryck et al., ESSOS 10] Servers configure access scopes where requests can be initiated. Browsers enforce access control Can defend both CSRF and SSRF attacks W3C drafts specs on fine-grained configuration  Limitation: Access scope policies carry sensitive information  Question: Can we limit disclosure of sensitive information while allowing access control?

8. 8 Our Work  Build DeRef, a practical system that can defend different variants of CSRF and SSRF attacks  Enable fine-grained access configurations  Identify forged requests in privacy-preserving manner, without disclosing private information of both browser and website  Implement a proof-of-concept prototype atop Firefox and WordPress  feasible deployment

9. 9 Definitions  Initiating URLs URLs that directly/indirectly initiate requests e.g., referer URLs, or URLs of current iframe and ancestor iframes  Target URLs destination URLs Initiating URLs Target URL

10. 10 Threat Model  Websites can configure target URLs to be protected initiating URLs that are legitimate to send requests to protected target URLs  A request is forged if target URL is protected, but initiated URLs are not legitimate Strip authentication credentials (including cookies and authentication headers) from forged requests  Aim to defend both CSRF and SSRF attacks

11. 11 Fine-Grained Access Control in DeRef  DeRef is built on two access control lists (ACLs): I-ACL: legitimate initiating URLs T-ACL: protected target URLs  ACLs are configured with scopes Based on scheme://domain/path e.g., http://.foo.com/dir  ACLs are transformed to “privacy-preserving” lists and stored in a policy file, which is publicized on website  DeRef’s browser plugin checks scopes defined in the policy file, and caches recently checked scopes

12. 12 Privacy-Preserving Goals  Protect client’s private information When browser checks if a URL is defined by a ACL, it does not reveal the URL to the website  Protect website’s private information Browser does not know website’s configured scopes unless the scope matches the URL  DeRef’s approach: two-phase checking Hash checking: checks if a scope potentially matches ACLs Blind checking: checks if a scope actually matches ACLs

13. 13 Hash Checking  Let x 1 … x L be a list of L configured scopes s be a random salt h(.) be a k-bit one-way hash function  Website sends h(s,x 1 ), h(s,x 2 ), …, h(s,x L ) to browser

14. 14 Hash Checking  To check if a URL y is defined in the configured scopes, we enumerate all possible scopes associated with y  For example, we have y = http://abc.com/a.htmlhttp://abc.com/a.html  We need to check http://.com/a.html http://.com/ http://abc.cm/a.html http://abc.com/

15. 15 Hash Checking  Hash length k determines the degree of privacy of the website’s configured scope Large k  attacker more likely find configured scopes e.g., by offline dictionary attack with popular URLs Small k  have many false positives e.g., if k = 4, 1/2 4 = 1/16 of URLs in entire web will match  Good value of k Filter out invalid scopes Preserve the privacy of configured scopes  k is tunable depending on application needs

16. 16 Blind Checking  Built on privacy-preserving matching protocol [R. Nojima et al., Trans. on Data Privacy 09] Based on Chaum’s RSA blind signature [Chaum, Crypto 83]  Idea (details in paper): In bootstrap phase, website sends a list of signed hashes, which “hide” the configured scopes Browser sends blinded hash for scope that passes hash checking Website signs blinded hash and returns to browser Browser unblinds signed hash and checks against a list of signed hashes

17. 17 Two-Phase Privacy-Preserving Checking  Phase 1: hash checking Filter out scopes that are not configured in ACLs Reduce blind checking steps Hash checking does not produce false negative  Phase 2: blind checking Eliminate the false positives from hash checking

18. 18 Implementation  Client-side: Implement a Firefox plugin in Javascript Intercepts HTTP/HTTPS messages Enforces two-phase checking Strips session information from forged requests  Server-side: Implement a plugin in WordPress 2.0 in PHP  Backward compatible if only one side supports DeRef  allows incremental deployment

19. 19 Evaluation  Goal: study response time overhead of DeRef in real deployment compared to without DeRef Deploy three machines in a LAN: client (Firefox), target website (WordPress), malicious website  Three scenarios: #1: Browsing insensitive webpages (normal usage) #2: Browsing sensitive webpages (e.g., logins) #3: Browsing malicious webpages that trigger CSRF attacks

20. 20 Results  #1: normal usage only has minimal overhead  #2: sensitive webpages have high overhead Two-phase checking on both I-ACL and T-ACL  #3: malicious webpages have overhead Two-phase checking on T-ACL only (since initiating URLs not configured in I-ACL)  Caching recently checked scopes reduces overhead to < 20% #1#2#3 IndexAdminLoginCSRFLogin CSRF No DeRef132.44 ms174.56 ms230.06 ms64.41 ms55.83 ms DeRef (no cache) 137.23 ms (4 %) 654.72 ms (275 %) 581.15 ms (154 %) 117.57 ms (83 %) 111.09 ms (99 %) DeRef (with cache) 138.01 ms (4 %) 200.27 ms (15 %) 254.27 ms (11 %) 76.07 ms (18 %) 66.4 ms (19 %)

21. 21 Trade-off between Performance and Privacy  Larger k --> processing time decreases Hash checking filters more non-configured URLs Blind checking likely to be skipped  Trade-off between performance and privacy by varying k

22. 22 Conclusions  DeRef: a practical system that defends a general class of request forgery attacks Enable fine-grained access control in a privacy- preserving manner Use tunable two-phase checking to trade-off between performance privacy Implement a proof-of-concept prototype atop Firefox and WordPress  Source code: http://ansrlab.cse.cuhk.edu.hk/software/deref