Validate/Requiring an incoming crumb even if CORS origin does not match

[briandela]

I wanted to get your thoughts on validating/requiring an incoming crumb value (cookie/payload), even if the CORS origin does not match.

I know setting a crumb cookie when the CORS origin does not match is considered token leaking but would it be possible to require the existence of a crumb to be present and that crumb to be valid?

For example, here are some scenarios (how it works today):

• with cors disabled
  • if I don't have a crumb or it's not valid, the request will 403
• with cors enabled and a matching cors origin
  • if I don't have a crumb or it's not valid, the request will 403
• with cors enabled, and a non-matching origin
  • the presence or lack of crumb doesn't make any difference and the request handler will run normally, as in today's code, generateCrumb is not called and it is critical to the validation flow.

Would it be possible to change the code flow so that in the final scenario, the with cors enabled, and a non-matching origin, the code still checks for a valid crumb? I believe it would involve refactoring the code a bit to separate the crumb validation from the generate call; it looks like today that generate has two responsibilities:

1. read the current crumb cookie and if it exists, set the value of it to request.plugins.crumb (the existence of request.plugins.crumb is later used to determine if a check should even happen on the crumb)
2. read the current crumb cookie, and if it does not exist, generate a crumb, and set a cookie for the response using reply.state, and set the value to request.plugins.crumb

When the CORS origins do not match, 2. above is the potential for leaking the CSRF cookie as it would set a crumb, but I also think that 1. could be achieved independently of 2., by not having generate have multiple responsibilities, and thus still validate CSRF for non-matching CORS origins?

Thoughts on this @stongo? I'll gladly submit a PR if you think it would be an acceptable way forward.

[stongo]

@briandela how is a CSRF going to occur on a CORS route from a non-matching origin? The request from a browser should never trigger the onPostAuth and onPreResponse handlers if it's not a matching allowed origin.

[briandela]

@stongo Completely forgot to respond to this. We were hoping to use crumb as a protection also against the curl scenario. Completely understand that CSRF/CORS is "browser" specific and in theory both CORS and CSRF should be enabled at the same time and that's the focus of crumb.

We completely understand that we are overloading crumb right now for something it wasn't intended to do (in addition to using it for standard CSRF).

Contrived example: we have multiple services that talk to each other. We use a crumb from one, to verify the call came from our system. We achieve this by using a shared iron encryption key across two services. If the payload matches the value in the encrypted cookie, we know that the crumb was generated by another part of system.

Again, this is not perfect as it just requires an automated call to one system to get a cookie for a replay against another but we have plenty of protections for that.

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.