New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CSRF protection can be bypassed #77
Comments
|
It's been a while since I last looked into this so excuse me if I'm slightly out of date :). As far as I remember, CSRF attacks are when a user submits a request by clicking a link or even visiting a malicious site. Last I checked (but this could have been 2 years ago), being able to submit anything in the header was sufficient to determine that a request is not a CSRF attack, as setting a header requires running a script (and if a script can be run, than we are dealing with XSS, which is a more serious problem but not in scope here). But of course new attack vectors might have surfaced, and double-submit cookies might no longer be sufficient. I don't have the capacity right now to investigate, so maybe you could share some recommendations on an implementation that would be more secure? And how an attack against the current one can be carried out? Thanks! |
|
Hi Adam, Thanks for getting back on this one. The issue was detected during a security test by an external company. On the OWASP site there are some recommendations on how to mitigate this risk: herehttps://owasp.org/www-community/attacks/csrf |
|
Hi Willem, |
|
per OWASP recommendations using secure hash of session cookie is discouraged. Suggested approach is to either encrypt the cookie or to use HMAC of the token as a cookie. For sure it would be valuable addition to the library, so PR is welcome :) Looks like HMAC may be simpler to implement, but any of the solutions recommended by OWASP is fine.
Picking up on this one: how I could see this working would be:
- establish a single server secret
- on first GET request create a plain text date/timestamp, generate
HMAC(timestamp) using the server secret.
- use the concatenation of the HMAC(timestamp) (=<hmac>) and the plaintext
timestamp (<ts>) as the CSRF cookie value (<hmac><ts>) and put this in the
response
- on subsequent POST request client will send CSRF cookie as well as cookie
value in XSRF request header
- server will compare both values and should be equal
- server will use server secret to create HMAC(timestamp) of the timestamp
(<ts>) found in CSRF cookie value (<hmac><ts>) and compare it to the HMAC
(<hmac>) also found in the CSRF cookie value (<hmac><ts>)
- additionally server could check if timestamp is recent enough to still be
trusted
This way the CSRF cookie value is not bound to the session ID yet for an
attacker it is impossible to generate a valid CSRF cookie value because
they don't know the server secret.
Do you think this is a valid approach? If yes I can try to submit a PR with
an implementation.
…On Thu, Dec 3, 2020 at 11:32 AM Michał ***@***.***> wrote:
Hi Willem,
per OWASP recommendations
<https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie>
using secure hash of session cookie is discouraged. Suggested approach is
to either encrypt the cookie or to use HMAC of the token as a cookie. For
sure it would be valuable addition to the library, so PR is welcome :)
Looks like HMAC may be simpler to implement, but any of the solutions
recommended by OWASP is fine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIHMP2XNATXY3GMLEY3U23SS5SK5ANCNFSM4UBESQBA>
.
|
|
Hi @adamw / @mszczygiel , I created a PR with a minimal implementation of the suggested CSRF improvement. Thanks, |
|
@willemvermeer great! you should fork the repository to your account, push the branch, then you should be able to open a PR against the original one (this one :) ) |
|
@willemvermeer thanks, taking a look now. Sorry it took so long, but we've been mostly away for Christmas / New Year :) |
|
Thanks @adamw ; I addressed your comments in a followup commit. And no apologies required for taking a Xmas break :-) |
|
@willemvermeer I suppose this can be closed now? |
Hi again,
Another question about the CSRF protection. It can be bypassed by forging a request that contains the same value for both the X-XSRF-TOKEN header and the XSRF-TOKEN cookie value. Any value will do since the only check that is now performed in randomTokenCsrfProtection is for those two values to be equal and non-empty.
Would it be somehow possible to conform to the OWASP recommendations described here what do you think would be the best approach?
Thanks,
Willem
The text was updated successfully, but these errors were encountered: