A Privacy-Preserving Defense Mechanism Against Request Forgery Attacks

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
• TrustCom11

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
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 clients
  knowledge
• OWASP Top 10 Application Security Risks in 2010

4
How CSRF Works
Malicious Website
Browser
Target Website

• Root cause of CSRF
• Existing browsers do not check whether a client
  actually initiates an HTTP request

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
Related Work

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

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

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
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
• DeRefs browser plugin checks scopes defined in
  the policy file, and caches recently checked
  scopes

12
Privacy-Preserving Goals

• Protect clients private information
• When browser checks if a URL is defined by a ACL,
  it does not reveal the URL to the website
• Protect websites private information
• Browser does not know websites configured scopes
  unless the scope matches the URL
• DeRefs approach two-phase checking
• Hash checking checks if a scope potentially
  matches ACLs
• Blind checking checks if a scope actually
  matches ACLs

13
Hash Checking

• Let
• x1 xL 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,x1), h(s,x2), , h(s,xL) to
  browser

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.html
• We need to check
• http//.com/a.html
• http//.com/
• http//abc.cm/a.html
• http//abc.com/

15
Hash Checking

• Hash length k determines the degree of privacy of
  the websites 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/24 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
Blind Checking

• Built on privacy-preserving matching protocol
  R. Nojima et al., Trans. on Data Privacy 09
• Based on Chaums 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
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
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
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
Results
1 2 2 3 3
Index Admin Login CSRF Login CSRF
No DeRef 132.44 ms 174.56 ms 230.06 ms 64.41 ms 55.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 )

• 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 lt 20

21
Trade-off between Performance and Privacy

• Larger k --gt 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
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