1. technology and computing
2. programming languages
3. javascript

Robust Defenses for Cross-Site Request
Forgery
CS6V81 - 005
Presented by
Saravana 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 crosssite request to the login form with attacker's credentials,
logging the victim into the honest website as the attacker.
Overview – Defense Techniques
o
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 Defined
o
o
o
CSRF exploits the trust that a site has in a user's browser
unlike the trust a user has for a particular site.
Browser's security policy allows web sites to send HTTP
requests to any network address.
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.
Existing CSRF Defense
●
Techniques for generating and validating tokens
Session 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 tokens
Session 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 tokens
Session-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 tokens
HMAC 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.
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 .
PROPOSAL
●
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.
Conclusion
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.
Questions