Robust Defenses for Cross-Site Request Forgery

CS6V81 - 005

Presented bySaravana M Subramanian

Gmail hacked !!!

– In late 2007 Gmail had CSRF vulnerability.– While being logged into Gmail, if the user visited a

malicious site, the site could generate a request to Gmail that Gmail treated as part of its on going session with the victim.

– A web attacker exploited this CSRF vulnerability to inject an email filter into David Airey's Gmail account, by causing the malicious page to perform a multipart/form-data POST to one of the Gmail interfaces.

– This filter would forward all the e-mails to attackers email.– Unfortunately the attacker gained access to davidairey.com

as Airey's domain registrar used email authentication, leading to significant inconvenience and financial loss.

Overview

● Cross-Site Request Forgery (CSRF)– In CSRF attack, a malicious site instructs a victims

browser to send a request to an honest site, as if the request were part of the victim’s interaction with the honest site, leveraging the victim’s network connectivity and the browser’s state, to disrupt the integrity of the victim’s session

● Login Cross-Site Request Forgery– In this variation of CSRF attack, the attacker forges a

cross-site request to the login form with attacker's credentials, logging the victim into the honest website as the attacker.

Overview – Defense Techniqueso Validating a secret token

Include a secret token with each request and to validate that the recieved token is correctly bound to the user's session.

o Validating the HTTP Referer header

Accept requests only from trusted sources by verifying the referer header.

o Validating custom header

Set a custom header via XMLHttpRequest and validating that header before state modifying requests.

CSRF Definedo CSRF exploits the trust that a site has in a user's

browser unlike the trust a user has for a particular site.

o Browser's security policy allows web sites to send HTTP requests to any network address.

o This vulnerabiliy would allow the attacker to control content rendered by the browser. The attacker could send requests to other machines

behind the firewall using the user's browser.

Requests sent via the browser's network stack typically include browser state such as cookies, client certificates or basic authentication headers.

CSRF Defined – Threat Models

● Forum Poster– Websites such as forums let users to submit passive

contents such as images or hyperlinks.– Eg: The attacker could craft a HTML image element

that references victim's bank site (instead of image element).

<img src = "http://bank.example.com/withdraw?account=bob&amount= 1000000&for=Fred">

CSRF Defined – Threat Models

● Web Attacker– The attacker owns a domain name e.g

attacker.com, has a valid HTTPS certificate and operates a web server.

– If a user visits this website, the attacker could mount a CSRF attack by instructing the browser to issue cross-site requests using both the GET and POST methods.

● Network Attacker– The attacker controls the user's network connection.– A compromised DNS server can be exploited by the

attacker to control the user's network.

Login CSRF- User perspective

● User visits the honest website and logs in.● The user then loads the attacker website or

encounter’s attacker iframe on another site.● Attacker sends HTTP request to the honest

site● Victim site assumes the request originate from

itself

Login CSRF- What really happened

● The attacker forges a login request to an honest site using the attacker’s user name and password at the honest site.

● If forgery succeeds the server responds with a set cookie header that instructs the user's browser to mutate its state by storing a session cookie.

● Now the user is logged into the honest site as the attacker.

Login CSRF- What really happened

Existing CSRF Defense

● Secret Validation token– We use a validation token to determine whether the

request came from an authorized source.– Validation token must be hard to guess by the

attacker– If the request is missing a validation token or the

token does not match the expected value the server should reject the request.

● Techniques for generating and validating tokensSession Identifier

– The user's session identifier is used as the secret validation token.

– On every request the server validates if the token matches the session identifier.

– Disadvantage is that anyone who reads the contents of the page, which contains the user's session identifier in the form of CSRF token, can impersonate the user till the session expires

Existing CSRF Defense

● Techniques for generating and validating tokensSession Independent Nonce

– Instead of using the user’s session identifier, the server stores a random nonce 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 is that an active network attacker can overwrite the session independent nonce with his or her own CSRF token, even if the web application is hosted on the HTTPS.

Existing CSRF Defense

● Techniques for generating and validating tokensSession-Dependent Nonce

– As a refinement of nonce technique, the server stores the state that binds the user's CSRF 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 is that the server needs to maintain a large state table to validate the tokens.

Existing CSRF Defense

● Techniques for generating and validating tokensHMAC of Session Identifier

– Instead of using the server side state to bind the CSRF token to the session identifier we use cryptography to bind the two values.

– As long as the site's server share the HMAC key each server can validate the CSRF token.

– HMAC ensures that an attacker who learns the user's CSRF token cannot infer the user's session identifier.

Existing CSRF Defense

● Where the Secret validation token fails– Many websites and CSRF frameworks fail to implement

secret token defense correctly.

– One common mistake is to leak the CSRF token during cross site request.

– Eg. If the honest site appends the CSRF token to the hyperlinks to another website then that website gains the ability to forge cross-site requests against the honest site.

Existing CSRF Defense

● The Referer Header– When the browser issues an HTTP request, it includes a

referer header that indicates which URL initiated the request.

– This information in the Referer header could be used to distinguish between same site request and cross site request.

CSRF Defense

● Privacy Issues with Referer header– The referer contains senstive information that impinges

on the privacy– The referer header reveals contents of the search

query that lead to visit a website.– Some organizations are concerned that confidential

information about their corporate intranet might leak to external websites via Referer header

CSRF Defense

● Referer header Implementation

Lenient Referer Validation– The site blocks request whose referer header has

incorrect value– If the request lacks the header then the site accepts the

request.– Disadvantage is that the attacker can cause the web

browser to suppress the referer header.– Eg. Request issued from ftp and data URLs do not

carry Referer headers.

CSRF Defense

● Referer header Implementation

Strict Referer Validation– The site blocks the request whose referer header has

incorrect value and also blocks request that lack a referer header.

– Disadvantage is that some browsers and network configurations suppress referer header for legitimate requests.

CSRF Defense

● Feasibility of Referer Header implementation– Strict referer validation is feasible over HTTPS because

only a tiny percentage (0.05 to 0.22%) of browsers suppress the header and most login requests are typically issued over HTTPS.

– Over HTTP, sites cannot afford to block requests for lack of a referer header because they would cease to be compatible with sizable percentage of users (3 – 11%).

CSRF Defense

● Custom HTTP Headers– Browsers prevent sites from sending custom HTTP

headers to another site but allow sites to send custom HTTP headers to themselves.

– Cookie value is not actually required to prevent CSRF attacks, the mere presence of the header is sufficient.

– To use this scheme as a CSRF Defense, a site must issue all state modifying requests using XMLHttpRequest, attach the header and reject all requests that do not accompany the header .

CSRF Defense

● Origin Header.– Modify the browsers to send a Origin Header with POST

request that identifies the origin that initiated the request.

– Origin header improves on the referer header by respecting the user's privacy.

– Origin header includes the information only needed to identify the party that initiated the request (scheme, host and port of the active document)

– It does not contain path or query portion of the URL.

– Origin header is sent only for POST requests while Refer header is sent for all request.

PROPOSAL

● Origin Header.To use origin header the sites should behave as follows:

– All state modifying requests, including login requests must be sent using the POST method.

– All state modifying GET requests must be blocked

– If origin header is present, the server must reject any requests whose Origin header contains an undesired value.

– For eg, a site could reject all requests whose origin indicated the request was initiated from another site.

PROPOSAL

● Impementation– Origin header was implemented in browser side in eight-line

patch to WebKit, open source safari component and in a 466 line extension to firefox.

– On the server side origin header was used to implement a web application firewall for CSRF in three lines of ModSecurity, a firewall language for apache.

PROPOSAL

Different CSRF defenses for different use cases– Strict referer validation to protect against login CSRF because

login forms typically submit over HTTPS.

– Sites that incorporate third party content such as images and hyperlink should use a framework that implements secret token validation, eg. Ruby-on-Rails .

– In the long term, the propose origin header that improves on privacy issues of Referer validation and eliminates the need for secret token defenses, allowing sites to protect both HTTPS and non HTTPS requests could be implemented as a CSRF defense.

Conclusion

Questions