Add (more) CSRF protection

[SergioBenitez]

CSRF is a thing. Protect against it automatically in forms.

[jrozner]

Tying this specifically to forms is a bad idea because it makes supporting Single Page Applications (SPAs) written in JavaScript more difficult and can break support for AJAX requests that use json/xml APIs. It's common for those applications to send the token in an HTTP request header instead of in the form body, especially if the body isn't a standard form encoded value (eg. JSON, XML), because it's easier to simply add a header before a request is sent than have to rewrite the DOM each time a request is made.

A common way to handle this is to provide two code paths for the check determined by the presence and value of the X-Requested-With header. jQuery specifically, and other AJAX libraries, set the X-Requested-With header before sending a request and set the value to "XMLHttpRequest". In the case that the header isn't set or it's not that value defaulting to looking in the form payload for the specified value is the correct place to find the token. Otherwise, if the header is set and it denotes an xhr you look in the header for the token.

It's also worth noting that a reasonable implementation should depend on sessions existing for storage of the token. I'm happy to help work on this if it's not already being done.

[golddranks]

I'd like to also have CSRF protection by default on when accessing the site with any mutating HTTP method, like POST, PUT or DELETE. At least check the origin + referer by default in these cases, and make it easy to additionally annotate routes that need checking, plus make it easy to have a HTTP header or cookie based check too.

[scull7]

Is there anyone working on this? If not, I wouldn't mind having a go at it. I believe that checking for a header token and then falling back to the form body would cover most cases (80/20 rule).

[SergioBenitez]

With a rather large sigh of grief, I'm pushing this to 0.4.

Implementing this in a simple, efficient, and straightforward manner has been a challenging endeavor. While it's simple to validate the incoming request against CSRF, it's not simple to emit a response with the appropriate information for later validation. In particular, we'd like to make it easy and efficient to insert a CSRF token into a web form in a template. To complete the defense mechanism, we need to insert the same token into a cookie. This presents a challenge: how do we know that a token has been inserted into a template so that we can then use the same token as a cookie in the response?

I have two candidate solutions, each with a somewhat large drawback.

1. Use a global per-thread token generator.

   The per-thread token generator would expose three functions/methods, get_token() -> Token, reset() and last_token() -> Option<Token>. When a new request is received, reset() is called. The call should be a noop under most conditions. A template helper is exposed that calls get_token() to get an appropriate CSRF token. When Template generates the final response, it calls last_token() after rendering the template to determine if a CSRF token was used. If one was used, it is inserted into the response as a cookie.

   There are two major drawback here. First, we've introduced "global" state. Rocket works hard to keep all state local; this would be the only "global" state. Second, this approach won't work when more than one task maps to a single thread (i.e, with coroutines or futures).

2. Add support for rendering state to existing template engines.

   In this approach, each template engine is extended with the ability to hold "rendering" state: state that is generated by helpers at render time. This means that we can implement a CSRF token generator helper than records, in local template state at render time, if and which token was generated. This even allows multiple tokens to be generated for a given template. The Template responder then simply queries this state after rendering the template to retrieve the CSRF token, if any, and inject it as a cookie into the response.

   The drawback to this approach is that we need buy-in from template engine authors. It also means that we would depend on this feature being present for any newly supported template engines if automatic CSRF protection is desired.

I believe that choice #2 above is a better approach. I'm against adding any kind of global state, though I'll note that this is precisely what other frameworks use to implement this kind of automatic CSRF protection. Any thoughts, suggestions, or ideas on this matter would be greatly appreciated. This is an important feature to have, and I'm excited to really nail down a good solution here.

[jrozner]

I'm not following why global state is needed for implementing the token system or why the design of 1 is being considered. Validation and generation can always happen at request time before a response with the template ever occurs. Typically the way most frameworks handle this is when a request comes in the framework determines if the request requires a token and if it needs to be validated. If not, it's simply a nop and the the request/response cycle goes through as expected. In the case where a token needs to be validated one of two events can happen:

1. The token is valid and a new token is generated/rotated (this should be stored in the session) and the request continues
2. The token is invalid/missing and a new token is generated/rotated (this should be stored in the session) and the request is stopped

You should never need to know a prior token's value and that information should not need to be kept around or generated at template generation time. Furthermore you also shouldn't need to expose a global, the template's scope just needs to include access to the session where the token can be taken out of it.

[SergioBenitez]

As I said in my previous comment:

While it's simple to validate the incoming request against CSRF, it's not simple to emit a response with the appropriate information for later validation.

Validation is easy, as you've determined. As is generating a new token. The hard part (for us) is inserting that token in two places: a template and a cookie. We want to use a new token for each response requiring one, and we don't want to generate a new token unless we're going to eventually use it. Thus, generating a new token each time a request is received is a non-starter.

You say:

...the template's scope just needs to include access to the session where the token can be taken out of it.

But that's exactly part of the issue; how do you do that? You've already assumed that there's some global session that we can simply refer to: there isn't. We also can't simply inject information into a template's scope: the user specifies the scope. It is conceivable that we can extend existing template engines with a second, framework provided scope. This would be equivalent to my second proposal except with information flowing the inverse direction.

Let me try to be as clear as possible. In a template, a user should be able to write something like:

<form ..>
  <!-- in practice, a form helper will generate the form tag AND the token field -->
  {% csrf_token %}
</form>

Rocket should generate the CSRF token hidden field from the csrf_token helper. Then, when a response is sent to the client, Rocket should include a CSRF token cookie with the same value as that in the form field. Rocket shouldn't send a cookie unless a token was used (though there's no harm in doing so), and Rocket should generate a new token for each response requiring a token.

You should never need to know a prior token's value and that information should not need to be kept around or generated at template generation time.

In my proposal, last_token() returns the token that was just generated so that a cookie can be created with its value, not a token used in a previous response. This is required information; there's no way around it. Something needs to know which token value was used in the response's HTML to include it in the response as a cookie. Other web frameworks use global state (such as server-side sessions) to do this; we don't have that ability.

[jrozner]

I understand the issue now. One suggestion I have, and this may not be the popular opinion or desired behavior, is to not try and push the token injection into the templates as part of rocket. I think unless rocket is dictating the template/rendering engine. The reason I say this is a couple reasons: First, There's going to be a lot of variation and support needed as well as buy in from all the developers working on the engines. Second, The updating of the tokens itself is going to be very app specific and going to be difficult to impossible to handle without providing a frontend js component like Rails does with it's UJS. If the application is using xhr the template may not be re-rendered and rotating the token on the server side (especially if it wasn't validated) will immediately break the page.

In my day job we had to solve this problem for apps that use our security plugin and what we did was append some JavaScript to the end of the any responses that have a handful of characteristics (content-type, etc.). This puts a small wrapper around the xhr code as well as adds an event listener into the dom and delegates to a handful of elements (submit, a, button) to add tokens into xhr requests from a cookie do some clever dom manipulation to drop the token into forms before the request is submitted. This let's us avoid parsing the response and manipulating it to try and put the tokens into the forms. The parsing wont be an issue for Rocket because the location is going to explicitly be set for where insertion is needed but this would solve the issue of tokens updating and the dom not being rewritten.

This solution is sort of out of the scope of Rocket as a rust based web framework but it's a solution that we've found solves some of these problems well.

[DemiMarie]

@SergioBenitez May I ask why?

Generating a token is easy. It should be as simple as grabbing a few bytes from an optimized implementation of ChaCha20 or (if AES-NI is available) AES256-CTR. Much, much less effort than the upstream proxy server spent decrypting the incoming HTTPS request.

Regarding sessions: Rocket already supports authenticated encryption of cookies. That means that we can store the token client side without any security loss. Client side code can still read the token, but can’t tamper with it without being detected (resulting in a 400 Bad Request error), nor can it make any sense of its contents.

Finally, just checking Origin and Referer headers would go a LONG way towards improving security.