Robust Defenses for Cross-Site Request Forgery

University of Cyprus Department of Computer Science Advanced Security Topics Robust Defenses for Cross-Site Request Forgery Name: Elena Prodromou Instructor: Dr. Elias Athanasopoulos Authors: Adam Barth, Collin Jackson, John C. Mitchell (Stanford University)

Outline What is Cross-Site Request Forgery (CSRF)? What is login Cross-Site Request Forgery? Which are the existing CSRF defenses? What s authors defense proposal? What are the vulnerabilities of Session Initialization? Conclusions and Advice CS682: Advanced Security Topics 2

What is Cross-Site Request Forgery (CSRF)? CSRF is among the twenty most exploited security vulnerabilities of 2007 The attacker leverages the victim s network connectivity and the browser s state, such as cookies, to disrupt the integrity of the victim s session with the honest site A malicious site instructs a victim s browser to send a request to an honest site CS682: Advanced Security Topics 3

History CSRF vulnerabilities have been known and in some cases exploited since 2001 Αs of 2007 there are few well documented examples: Netflix The online banking web application of ING Direct was vulnerable to a CSRF attack that allowed illicit money transfers YouTube was vulnerable to CSRF in 2008 and this allowed any attacker to perform nearly all actions of any user McAfee was vulnerable to CSRF and it allowed attackers to change their company system CS682: Advanced Security Topics 4

CSRF Defined Attacker take advantage of user s Network Connectivity Describes the extensive process of connecting various parts of a network to one another Read Browser State Requests sent via the browser s network stack typically include browser state, such as cookies, client certificates, or basic authentication headers Write Browser State The attacker causes the browser to issue a network request, the browser parses and acts on the response CS682: Advanced Security Topics 5

Attackers Forum Poster For example, if an attacker chooses the images URL maliciously, the network request might lead to a CSRF attack Web attacker A malicious principal who owns a domain name e.g. attacker.com, has a valid HTTPS certificate for attacker.com and operates a server. If the user visits attacker.com, the attacker can mount a CSRF attack by instructing the user s browser to issue cross-site requests using both GET and POST methods Network attacker A malicious principal who controls the user s network connection CS682: Advanced Security Topics 6

What is login Cross-Site Request Forgery? (1/2) An attacker uses the victim s browser to forge a cross-site request to the honest site s login URL, using the attacker s user name and password If the forgery succeeds, the honest server responds with a Set- Cookie header that instructs the browser to mutate its state by storing a session cookie, logging the user into the honest site as the attacker CS682: Advanced Security Topics 8

What is login Cross-Site Request Forgery? (2/2) A successful CSRF attack can be devastating for both the business and user CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it s impossible to distinguish a legitimate request from a forged one CS682: Advanced Security Topics 9

Examples of login CSRF Search History Search queries contain sensitive details about the user s interests and activities and could be used by an attacker to embarrass the user, to steal the user s identity or to spy on the user An attacker can spy on a user s search history by logging the user into the search engine as the attacker The user s search queries are stored in the attacker s search history The attacker can retrieve the queries by logging into his or her own account CS682: Advanced Security Topics 10

Search History Figure 1: The victim visit s the attacker s site and the attacker forges a cross-site request to Google s login form, causing the victim to be logged into Google as the attacker. Later, the victim makes a web search, which is logged in the attacker s search history.

Examples of login CSRF PayPal igoogle To mitigate the vulnerability they have deprecated the use of inline gadgets and deployed the secret validation token defense CS682: Advanced Security Topics 12

Examples of login CSRF CS682: Advanced Security Topics 13

Which are the existing CSRF defenses? 1 Secret Validation Token 2 The Referrer Header 3 Custom HTTP Headers CS682: Advanced Security Topics 15

Which are the existing CSRF defenses? 1Secret Validation Token Additional information in each HTTP request If a request is missing a validation token or the token does not match the expected value, the server should reject the request Can defend against login CSRF Difficult to implement, forget to implement Before login, there is no session to bind the CSRF token The site must: 1. First create a pre-session 2. Implement token-based CSRF protection 3. Transition to a real session after successful authentication CS682: Advanced Security Topics 16

Secret Validation Token Designs (1/2) Session Identifier Use the user s session identifier as the secret validation token Disadvantage: Users may reveal the contents of Web Pages that contain session identifiers to third parties Session- Independent Nonce Server generates a random nonce and stores it as a cookie when the user first visits the site On every request, the server validates that the token matches the value stored in the cookie Disadvantage: An active network attacker can overwrite the session independent nonce CS682: Advanced Security Topics 17

Secret Validation Token Designs (2/2) Session-Dependent Nonce Store state on the server that bind the user s CSRF token value to the user s session identifier On every request, the server validates that the supplied CSRF token is associated with the user s session identifier Disadvantage: Site must maintain a large state table HMAC of Session Identifier Cryptography is used to bind the CSRF token and the session identifier All site servers share the HMAC key and each server can validate that the CSRF token is correctly bound to the session identifier An attacker who learns a user s token cannot infer the user s session identifier * HMAC = Hash Message Authentication Code CS682: Advanced Security Topics 18

Which are the existing CSRF defenses? 2 The Referrer Header Indicates which URL initialized the request Prevents CSRF by accepting requests only from trusted sources Referrer disadvantages: Usually suppressed due to privacy information leaking and can be spoofed due to browser bugs Referrer Validation as a CSRF defense In lenient Referrer validation, the site blocks requests whose Referrer header has an incorrect value. If a request lacks the header, the site accepts the request. A Web attacker can cause the browser to suppress the Referrer header. In Strict Referrer validation, the site blocks requests that lack a Referrer header. Protects against malicious Referrer suppression but incurs a compatibility penalty as some browsers and network configurations suppress the Referrer header for legitimate requests. CS682: Advanced Security Topics 19

Design Experiment (1/4) They used two advertisement networks Used two servers with two domain names to host the advertisement Advertisement generates a unique id and randomly selects the primary server Primary server sends the client HTML that issues a sequence of GET and POST requests to their servers, both over HTTP and HTTPS Requests are generated by submitting forms, requesting images, and issuing XMLHttpRequests The advertisement generates both same-domain requests to the primary server and cross-domain requests to the secondary server Servers logged request parameters (Session identifier, Referrer etc) Servers recorded the value of document.referrer DOM API CS682: Advanced Security Topics 20

Experiment (2/4) Results The Referrer header is suppressed more often for cross domain requests over HTTP The Referrer header is suppressed more often for HTTP requests than for HTTPS requests The Referrer header is suppressed more often in Ad Network B than on Ad Network A for all types of request Figure 2: Requests with a Missing or Incorrect Referrer Header (283,945 observations). The x and y represent the domain names of the primary and secondary web servers, respectively. 21

Experiment (3/4) Figure 3: Requests with a Missing or Incorrect Referrer Header on Ad Network A (241,483 observations). Opera blocks cross-site document.referrer for HTTPS. Firefox 1.0 and 1.5 do not send Referrer for XMLHttpRequest. The PlayStation 3 (denoted PS) does not support document.referrer. Browsers that suppress the Referrer header also suppress the document. referrer value CS682: Advanced Security Topics 22

Experiment (4/4) Conclusion Strict Referrer validation can be used as CSRF defense for HTTPS (0.05-0.22% of browsers suppress the header over https) Strict Referrer validation is well-suited for preventing login CSRF because login requests are issued over HTTPS Over HTTP, sites cannot afford to block requests that lack Referrer header because they would cease to be compatible with 3-11% of users CS682: Advanced Security Topics 23

Which are the existing CSRF defenses? 3 Custom HTTP Headers Browser prevents sites from sending custom HTTP headers to another site but allows sites to send custom HTTP headers to themselves using XMLHttpRequest To use custom headers as a CSRF defense a site must: Issue all state-modifying requests using XMLHTTPRequest Attach a custom header (e.g. X-Requested-By) Reject all state-modifying requests that are not accompanied by the header CS682: Advanced Security Topics 24

What s authors defense proposal?(1/3) Origin header The Origin header improves on the Referrer header by respecting the user s privacy Origin header includes only the information required to identify the principal that initiated the request (port, host, scheme) Origin header doesn t contain the path or query portions of the URL Origin header is sent only for POST requests Referrer header is sent for all requests Server Behavior All state-modifying requests, including login requests, must be sent using the POST method Server must reject any requests whose Origin header contains an undesired value or null CS682: Advanced Security Topics 26

What s authors defense proposal?(2/3) Security Analysis Rollback and Suppression A supporting browser will always include the Origin header when making POST requests DNS Rebinding Sites that rely only on network connectivity for authentication, could complementary validate the Host header. It applies to all CSRF defenses Plug-ins If a site opts into cross-site HTTP requests, an attacker can use Flash Player to set the Origin header in cross-site requests. Sites should not opt into cross-site HTTP requests from untrusted origins CS682: Advanced Security Topics 27

What s authors defense proposal?(3/3) Adoption Origin Header improves and unifies other proposals and has been adopted by several working groups Implementation They implemented both the browser and server components of the Origin header CSRF defense Browser side: WebKit, Safari, Firefox Server side: ModSecurity, Apache CS682: Advanced Security Topics 28

What are the vulnerabilities of Session Initialization? (1/4) Login CSRF is an example of vulnerability in session initialization Authenticated as User Authenticated as Attacker e.g. Login CSRF, PayPal Two common approaches to mount an attack on session initialization HTTP Requests Cookie Overwriting CS682: Advanced Security Topics 30

What are the vulnerabilities of Session Initialization? (2/4) HTTP Requests - OpenID Includes a self-signed nonce to protect against reply attacks but doesn t suggest a mechanism to bind the OpenID session to the user s browser 1Web attacker visits the Relying Party (Blogger) and begins the authentication process with the Identity Provider (Yahoo!) 2Identity Provider redirects the attacker s browser to the return to URL of the Relying Party 3Instead of following the redirect, the attacker directs the user s browser to the return to URL 4The Relying Party completes the OpenID protocol and stores a session cookie in the user s browser 5The user is now logged in as the attacker Defense Relying Party should generate a fresh nonce at the start of the protocol, store it in browser s cookie store and include it in the return to parameter of the OpenID protocol CS682: Advanced Security Topics 31

What are the vulnerabilities of Session Initialization? (3/4) HTTP Requests - PHP Cookieless Authentication Stores the user s session identifier in a query parameter Fails to bind the session to the user s browser, letting a web attacker force the user s browser to initialize a session authenticated as the attacker 1The web attacker logs into the honest web site 2The web attacker redirects the user s browser to the URL currently displayed in the attacker s location bar 3Because this URL contains the attacker s session identifier, the user is now logged in as the attacker Defense Site could maintain a long-lived frame that contains the session identifier token. This frame binds the session to the user s browser by storing the session identifier in memory CS682: Advanced Security Topics 32

What are the vulnerabilities of Session Initialization? (4/4) Cookie Overwriting A Set-Cookie header can contain a secure flag, indicating that it should be only sent over an HTTPS connection An active network attacker can supply a Set-Cookie header over a HTTP connection to the same host name as the site and install either a Secure or a non-secure cookie of the same name The secure flag does not offer integrity protection in the crossscheme threat model If the secure cookie contains the user s session identifier, an attacker can overwrite the user s session identifier with her own session identifier Defense Cookie-Integrity header in HTTPS requests, identifies the cookies that were set using HTTPS CS682: Advanced Security Topics 33

Conclusions and Advice Login CSRF Strict Referrer validation (login forms typically submit over HTTPS, where the Referrer header is reliably present for legitimate requests) If a login request lacks a Referrer header, the site should reject the request to defend against malicious suppression HTTPS For sites served over HTTPS (e.g. banking sites), the authors recommend strict Referrer validation Third-party Content Images, hyperlinks should use a framework that implements secret token validation correctly Origin header Eliminating the privacy concerns that lead the Referrer blocking HTTPS and non-https requests both work CS682: Advanced Security Topics 35

University of Cyprus Department of Computer Science Advanced Security Topics Robust Defenses for Cross-Site Request Forgery Name: Elena Prodromou Email: eprodr02@cs.ucy.ac.cy QUESTIONS? CS682: Advanced Security Topics 36