CSRF protection with custom headers (and without validating token)

Question

For a REST-api it seems that it is sufficient to check the presence of a custom header to protect against CSRF attacks, e.g. client sends

"X-Requested-By: whatever"

and the server checks the presence of "X-Requested-By" and drops the request if the header isn't found. The value of the header is irrelevant. This is how Jersey 1.9's CsrfProtectionFilter works and it is described in this blog post: http://blog.alutam.com/2011/09/14/jersey-and-cross-site-request-forgery-csrf/. The blog post also links to NSA and Stanford papers stating that the custom header itself is sufficient protection:

The first method involves setting custom headers for each REST request such as X-XSRF-Header. The value of this header does not matter; simply the presence should prevent CSRF attacks. If a request comes into a REST endpoint without the custom header then the request should be dropped.

HTTP requests from a web browser performed via form, image, iframe, etc are unable to set custom HTTP headers. The only way to create a HTTP request from a browser with a custom HTTP header is to use a technology such as Javascript XMLHttpRequest or Flash. These technologies can set custom HTTP headers, but have security policies built in to prevent web sites from sending requests to each other unless specifically allowed by policy. This means that a website www.bad.com cannot send a request to http://bank.example.com with the custom header X-XSRFHeader unless they use a technology such as a XMLHttpRequest. That technology would prevent such a request from being made unless the bank.example.com domain specifically allowed it. This then results in a REST endpoint that can only be called via XMLHttpRequest (or similar technology).

It is important to note that this method also prevents any direct access from a web browser to that REST endpoint. Web applications using this approach will need to interface with their REST endpoints via XMLHttpRequest or similar technology.

Source: Guidelines for implementing REST

It seems however, that most other approaches suggest that you should generate a token and also validate this on the server. Is this over-engineering? When would a "presence of" approach be secure, and when is also token validation required?

Answer 1

Security is about defence in depth. Simply checking the value is sufficient at the moment, but future technologies and attacks may be leveraged to break your protection. Testing for the presence of a token achieves the absolute minimum defence necessary to deal with current attacks. Adding the random token improves the security against potential future attack vectors. Using a per-request token also helps limit the damage done by an XSS vulnerability, since the attacker needs a way to steal a new token for every request they make.

This is the same reasoning used in modern cryptographic algorithms, where n rounds are considered a minimum for safety, but 2n+1 rounds (for example) are chosen in the official implementation to ensure a decent security margin.

Further reading:

• CSRF with JSON POST
• Why refresh CSRF token per form request?

Answer 2

TL;DR - Checking the existence of a non-standard header like "X-Requested-By" should be sufficient to guard against CSRF attacks without checking the value of the header.

Non-standard headers cannot be set in a CSRF attack

The Play framework site breaks it down really well:

Simply put, an attacker can coerce a victims browser to make the following types of requests:

• All GET requests
• POST requests with bodies of type application/x-www-form-urlencoded, multipart/form-data and text/plain

An attacker can not:

• Coerce the browser to use other request methods such as PUT and DELETE
• Coerce the browser to post other content types, such as application/json
• Coerce the browser to send new cookies, other than those that the server has already set
• Coerce the browser to set arbitrary headers, other than the normal headers the browser adds to requests

This makes sense if you consider the attack vectors for CSRF:

• GET requests (e.g. <img>, <iframe>) - which cannot set headers.
• <form> submitted by a user click - which are limited to a few specific headers.
• <form> submitted by JavaScript (HTMLFormElement.submit()) - which are limited to a few specific headers.

JavaScript is subject to the same-origin policy, so it can only add non-standard headers if one of the following conditions hold:

• it is "in-domain" (i.e. loaded from the same domain as the target of the request).
• it is allowed to do so through CORS.

XSS attacks are out of scope for this question

Non-standard headers can be set in an XSS attack. Using a non-standard header to prevent CSRF attacks does not make a site any more (or any less) vulnerable to XSS attacks regardless of the value of the header. Both non-standard headers and CSRF tokens are vulnerable to XSS attacks. If the XSS attacker can set a non-standard header on a request (e.g. in-domain XHR), he/she can certainly gain access to a CSRF token set in a cookie or embedded in DOM or in a JavaScript variable.

Reference

There is a similar SO question here which is confusing but came to the same conclusion.

Some examples of such non-standard headers in the wild:

• "X-Requested-By" (mentioned by OP) recognized by Jersey/others
• "X-Requested-With" set by jQuery
• "X-XSRF-TOKEN" set by Angular
• "X-CSRF-TOKEN" recognized by the Play framework

Answer 3

EDIT: this csrf-request-builder was exploiting a vulnerability in Flash, which has now been fixed. It is possible to send complex requests with JavaScript, however if you specify additional header elements a preflight OPTIONS HTTP request will be sent prior to the actual request.

I have verified that Jersey is vulnerable to CSRF and the developers of Jersey have been notified. It is possible to leverage this vulnerability using Flash and possibly other scripting technologies. Jersey is vulnerable because the "X-Requested-By" HTTP header is not on flash's header blacklist.

I used the CSRF-Request-Builder with the following arguments to build a post request:

file://var/code/CSRF-Request-Builder/csrf_payload.html#url=http://google.com&X-Requested-By=1&body={'test':1}

You should never come with with your own method of CSRF prevention unless you really understand CSRF exploitation. The CSRF Prevention Cheat sheet is a great resource.

Answer 4

https://stackoverflow.com/a/11423778/14731 makes a very important point: the Same Origin Policy (SOP) is concerned with preventing the reading of cross-domain responses, not with the writing of requests.

Meaning, while you might be able to write custom headers in the future, it is extremely unlikely that you would ever be able to read the response of a cross-domain request. As such, the best CSRF protections involve reading a secret value from the server, writing it back, and having the server validate the value.

You don't necessarily need server-side state to accomplish this (Double-Submit Cookies, and Encrypted Token Pattern are two examples of this) but you should validate some secret value on the server.

Answer 5

As of 2020, MDN now explicitly recommends 'To prevent cross-origin writes, check an unguessable token in the request — known as a Cross-Site Request Forgery (CSRF) token'. See https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy (scroll down to 'How to block cross-origin access').