A Privacy-Preserving Defense Mechanism Against Request Forgery Attacks - PowerPoint PPT Presentation


PPT – A Privacy-Preserving Defense Mechanism Against Request Forgery Attacks PowerPoint presentation | free to download - id: 5e5c62-MTI4M


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

A Privacy-Preserving Defense Mechanism Against Request Forgery Attacks


Title: PowerPoint Presentation Last modified by: pclee Created Date: 1/1/1601 12:00:00 AM Document presentation format: On-screen Show Other titles – PowerPoint PPT presentation

Number of Views:110
Avg rating:3.0/5.0
Slides: 23
Provided by: cseCuhkE1


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: A Privacy-Preserving Defense Mechanism Against Request Forgery Attacks

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

  • 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
  • Examples of state
  • Cookies
  • Authentication header
  • Data embedded GET/PUT requests

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

How CSRF Works
Malicious Website
Target Website
  • Root cause of CSRF
  • Existing browsers do not check whether a client
    actually initiates an HTTP request

General Request Forgery
  • Variants of CSRF
  • Login CSRF Barth et al., 08
  • Trigger forged login requests without active
  • 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

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

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?

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

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

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
  • Aim to defend both CSRF and SSRF attacks

Fine-Grained Access Control in DeRef
  • DeRef is built on two access control lists
  • 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

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

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

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/

Hash Checking
  • Hash length k determines the degree of privacy of
    the websites configured scope
  • Large k ? attacker more likely find configured
  • e.g., by offline dictionary attack with popular
  • 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

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

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

  • 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

  • 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

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

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

  • 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
About PowerShow.com