Handle request cookie in order to get csrf token.

[Jule-]

If there is no security reason for taking csrf token in request cookie I think we can handle it that way.

The benefit of this approach is that when your set credentials: 'same-origin' (or equivalent for whatever http client you use, I am using aurelia-fetch-client) by default the client send cookie with requests. If not we have to write http interceptor in order to add this header.

See: Requests with credentials

[Jule-]

Any chance this pull request being processed?

[grawk]

Hey @Jule- sorry for the delay. This looks good to me. Let me make sure someone else on the team gives it a thumbs up and we will move fwd asap

[Jule-]

Ok thank you! :)

[djMax]

This seems like a bad idea... You're validating the wrong thing. The fact that the user agent has access to the cookie doesn't tell you that the script that caused the request has access to the CSRF value.

[grawk]

Apologies! I was evaluating the line of code without giving enough thought to the context :( Given the bigger picture, this is not a change we should make.

[Jule-]

@djMax Sorry for my ignorance but what is the right thing to do so?

In fact, the cookie hold the CSRF token, right? So you mean that the user agent can send the domain cookie in the request while the script that caused the request can't access it? (Maybe can you point me some article on this attack please?) And as a consequence the right thing to do is to access the cookie in the script in order to recopy the CSRF token in the request headers in order to ensure that the script making the request is provided by the same domain? Am I right?

Thank you for your time.

[jasisk]

Sure. Here is a working exploit using your fork, with which I'm able to perform an action on behalf of a user without their permission.

At one point you mentioned you were using using a fetch library. If so, you can simply set request headers. In fact, there is a shorthand property for lusca: lusca.csrf({ angular: true }). If you use that, the csrf token is stored in a cookie called XSRF-TOKEN and will validate requests which have a 'X-XSRF-TOKEN' header. So, in your case, you'd want to parse out the token from document.cookie, and include it as a header when you perform your fetch.

Worth mentioning you don't have to use that shorthand; you can just set the cookie and header options yourself (that's all the angular option does).

[Jule-]

Indeed, thank you for your demonstration! I better understand how CSRF works now. Sorry bothering you with my ignorance! ;)