robust defenses for cross site request forgery cs6v81 005 presented by saravana m subramanian n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Robust Defenses for Cross-Site Request Forgery CS6V81 - 005 Presented by Saravana M Subramanian PowerPoint Presentation
Download Presentation
Robust Defenses for Cross-Site Request Forgery CS6V81 - 005 Presented by Saravana M Subramanian

Loading in 2 Seconds...

play fullscreen
1 / 27

Robust Defenses for Cross-Site Request Forgery CS6V81 - 005 Presented by Saravana M Subramanian - PowerPoint PPT Presentation


  • 152 Views
  • Uploaded on

Robust Defenses for Cross-Site Request Forgery CS6V81 - 005 Presented by Saravana M Subramanian. Gmail hacked !!!. In late 2007 G mail had CSRF vulnerability.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Robust Defenses for Cross-Site Request Forgery CS6V81 - 005 Presented by Saravana M Subramanian' - owen


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
robust defenses for cross site request forgery cs6v81 005 presented by saravana m subramanian
Robust Defenses for Cross-Site Request Forgery

CS6V81 - 005

Presented by

Saravana M Subramanian

gmail hacked
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 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.

overview
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 techniques
Overview – Defense Techniques

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 defined
CSRF Defined

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
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 models1
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
Login CSRF- User perspective

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

login csrf what really happened
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.

existing csrf defense
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 defense1
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
existing csrf defense2
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
existing csrf defense3
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
existing csrf defense4
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
existing csrf defense5
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
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
csrf defense1
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
csrf defense2
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
csrf defense3
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
csrf defense4
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
csrf defense5
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
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
proposal1
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
proposal2
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
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.

Conclusion