Revision as of 22:27, 21 January 2015

DRAFT DOCUMENT - WORK IN PROGRESS

Description

In short, CSRF abuses the trust relationship between browser and server. This means that anything that a server uses in order to establish trust with a browser (e.g., cookies, but also HTTP/Windows Authentication) is exactly what allows CSRF to take place - but this only the first piece for a successful CSRF attack.

The second piece is a web form or request which contains parameters predictable enough that an attacker could craft his own malicious form/request which, in turn, would be successfully accepted by the target service. Then, usually through social engineering or XSS, the victim would trigger that malicious form/request submission while authenticated to the legitimate service. This is where the browser/server trust is exploited.

In order to prevent CSRF in ASP.NET, anti-forgery tokens (also known as request verification tokens) must be utilized.

These tokens are simply randomly-generated values included in any form/request that warrants protection. Note that, ideally, this value should be unique for every actual form/request, not just for every type of form/request. This guarantees that every form/request is unique and, therefore, protected from CSRF.

Mitigation Examples

Please note that the following examples may not entail a complete anti-CSRF solution for any given Web application. Specific requirements may call for adjustments and/or combinations of different strategies.

Solutions NOT considered secure

- Assuming that SSL/TLS will thwart CSRF attacks just because the cookie is marked "Secure" and/or "HTTPOnly". The problem lies in the trust between legitimate browser and server. Therefore, the browser will just send its current cookies when the forged request is triggered. The attacker never has to touch any cookies.

- Referer header verification as the only protection. This can be easily manipulated.

- Cookie double-submission when the cookie utilized is the session cookie. This exposes the session cookie to JavaScript. Always mark the session cookie "HTTPOnly" so that it cannot be accessed with JavaScript.

- Any CSRF protection is null and void given the presence of XSS, for several reasons. The main and obvious reason is that, through XSS, the attacker can hijack the session and spoof the user, not even having to worry about performing CSRF.

Anti-CSRF Token

ASP.NET has the capability to generate anti-CSRF security tokens for consumption by your application, as such:

1) Authenticated user (has session which is managed by the framework) requests a page which contains form(s) that changes the server state (e.g., user options, account transfer, file upload, admin functions, etc.)

2) Generate the security token (or grab it from the session state) and send the token as a session cookie (again, managed in the session state, unique per session) as well as within a hidden value in each form.

3) Once the user submits the form, validate the token stored in the session state against the token included in the submitted form value. On failure, disregard form.

Effectively, this is the cookie double-submission approach done right, since the security token is submitted both as a cookie (managed in the framework session state) and within a hidden form value at the same time.

For implementation details, see:
CSRF Prevention (official ASP.NET blog)
Preventing CSRF Attacks (official ASP.NET blog)

You may consider making a new security token for every new request, rather than session:
Why refresh CSRF token per form request?

ViewState

Requirement:
EnableViewStateMac must be set.

The ASP.NET ViewState contains a property, ViewStateUserKey, which can offer protection against CSRF.

When enabling CSRF protection through the ViewState, the aim is to make the ViewState always unique per user session, serving as a kind of CSRF token. That's where MAC and the ViewStateUserKey come together.

EnableViewStateMac, when off, obviously performs no checks. When enabled, it will only perform tampering checks. Therefore, an attacker could obtain a valid (but unchanging) ViewState and still perform CSRF.

The ViewStateUserKey can add uniqueness to the equation if you set it to a new value for every session.

Setting ViewStateUserKey to the current Session ID is acceptable (again, when EnableViewStateMac is on).

For implementation details, see:
MSDN - Securing ViewState
MSDN - ViewStateUserKey

For an extra secure approach when using ViewState, see the section below.

ViewState + Token

The Token approach and the ViewState approach are not mutually exclusive.

This hybrid strategy still uses the ViewState as the main entity for CSRF protection. Keep in mind, however, that you're not constrained to setting ViewStateUserKey to the current Session ID.

By generating and validating tokens with HtmlHelper.AntiForgeryToken and ValidateAntiForgeryTokenAttribute (see CSRF Prevention), you can set the ViewStateUserKey to the token rather than the Session ID.

This gives you the flexibility to choose whether to refresh tokens per request or per session while adding additional defensive layers to your strategy.

Here's a blog post by Eric Johnson and James Jardine with an example of this implementation.

AJAX

Depending on your application, you'll likely have to choose between using HTTP Headers or POST data (or both!) to carry your anti-CSRF tokens.

Whatever you choose, the optimal validation method is indeed through tokens. This means you can follow the strategy outlined in the first section, "ASP.NET Tokens", while creating either a custom header to hold the token value or just sending the token with the rest of the POST data.

For more guidance, see the answers given to the following questions:
Anti-CSRF Cookie
CSRF Protection With Custom Headers

<MN: it seems to me that using the ViewState (rather than tokens) with XHRs is not optimal, but could probably be done. Should I mention anything about that? I doubt anyone even does that.>

Related Attacks

CSRF (Attack)
CSRF (Full Wikipedia Article)
XSS (Attack)

Related Vulnerabilities

XSS
Insecure Randomness
Insecure Third-Party Domain Access
Non-Cryptographic Pseudo-Random Number Generator

Related Controls

.NET CSRF Guard

Related Technical Impacts

Accountability
Confidentiality

References

Why refresh CSRF token per form request?
CSRF Prevention (official ASP.NET blog)
Preventing CSRF Attacks (official ASP.NET blog)
Anti-CSRF and Cookies
How to protect against CSRF by default in ASP.NET MVC 4?
How does ViewState protect against CSRF?
How To Fix CSRF using Microsoft .Net ViewStateUserKey and Double Submit Cookie, by Eric Johnson and James Jardine
CSRF Protection With Custom Headers (focus on the answer, not the question)
MSDN - Securing ViewState
MSDN - ViewStateUserKey
MSDN - HtmlHelper.AntiForgeryToken
MSDN - ValidateAntiForgeryTokenAttribute