Loading in 2 Seconds...
Loading in 2 Seconds...
Robust Defenses for Cross-Site Request Forgery CS6V81 - 005 Presented by Saravana M Subramanian. Gmail hacked !!!. In late 2007 G mail had CSRF vulnerability.
CS6V81 - 005
Saravana M Subramanian
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 oneof 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.
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.
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.
Validating the HTTP Referer header
Accept requests only from trusted sources by verifying the referer header.
Validating custom header
Set a custom header via XMLHttpRequest and validating that header before state modifying requests.
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.
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">
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.
The attacker controls the user's network connection.
A compromised DNS server can be exploited by the attacker to control the user's network.
User visits the honestwebsite and logs in.
The user thenloads the attackerwebsite or encounter’sattackeriframe on another site.
Attackersends HTTP request to the honest site
Victim site assumes the requestoriginatefromitself
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.
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.
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 expiresExisting CSRF Defense
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
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
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
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 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 headerCSRF Defense
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
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
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
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
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
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
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