[question] General CSRF Protection and Library Questions

[donaldthai]

Hi, I had a few questions regarding the library and general CSRF protection:

• This library uses the "Double-Submit" method, so that means that the token is only stored in the secure cookie and client side right? What stops an attacker from visiting a site with csrf protection setup to generate that secure cookie and masked token and forging a request for another user?

• Should the 32 byte auth key be tied to the user session to make it unique just for that particular user? Don't really see a way to do this with this library.

• Do login forms need CSRF protection? Does it make sense to generate a csrf token for it before login?

Thanks!

[elithrar]

This library uses the "Double-Submit" method, so that means that the token is only stored in the secure cookie and client side right? What stops an attacker from visiting a site with csrf protection setup to generate that secure cookie and masked token and forging a request for another user?

The attacker won't have the same cookie value as the user.

Should the 32 byte auth key be tied to the user session to make it unique just for that particular user? Don't really see a way to do this with this library.

It will always be unique - 32 bytes (256 bits) is a significant amount of entropy. An "attacker" could obtain 1 trillion cookies and still be unable to get the same value as another user.

Do login forms need CSRF protection? Does it make sense to generate a csrf token for it before login?

Yes, as a common CSRF attack would be to have a user login with attacker-provided credentials.

[donaldthai]

This library uses the "Double-Submit" method, so that means that the token is only stored in the secure cookie and client side right? What stops an attacker from visiting a site with csrf protection setup to generate that secure cookie and masked token and forging a request for another user?

The attacker won't have the same cookie value as the user.

I might be missing some key concepts about how "double-submit" works. Regardless if an attacker won't have the same cookie value, can't an attacker just use their cookie token value to forge a request since the server validates the unmasked and the decoded masked value?

[elithrar]

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie The attacker can't write cookies as your domain, unless: 1) They man-in-the-middle your connection (which is a whole class of problems - you're screwed anyway here) 2) They can read a user's cookie from malicious JavaScript inserted on your site (i.e. a compromised JS library, or XSS attack that adds JS) Otherwise, the user has a cookie, and your forms have a token, and they have to match. The attacker can't see the cookie due to the same-origin policy (unless #2), but the cookie will be submitted automatically for any requests to your site, so a cookie alone isn't enough. In fact, that cookies are _sent_ is exactly how CSRF attacks work: a user is logged in, and the attack tricks them into (often passively!) performing an action on your website that might cause harm - {transfer money, change password, remove 2FA, post hate-speech, etc}. So, your site ALSO embeds that value as part of the form. The attacker can't see the form, or the cookie value, and thus can't get you to submit a form that has a matching value.

…

On Wed, Dec 12, 2018 at 3:40 PM Donald T. ***@***.***> wrote: This library uses the "Double-Submit" method, so that means that the token is only stored in the secure cookie and client side right? What stops an attacker from visiting a site with csrf protection setup to generate that secure cookie and masked token and forging a request for another user? The attacker won't have the same cookie value as the user. I might be missing some key concepts about how "double-submit" works. Regardless if an attacker won't have the same cookie value, can't an attacker just use their cookie token value to forge a request since the server validates the unmasked and the decoded masked value? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcB4mlpNEmBC-WDWGci2R7WAmC47dks5u4ZPngaJpZM4ZQoXr> .

[donaldthai]

The attacker can't write cookies as your domain, unless:

1. They man-in-the-middle your connection (which is a whole class of problems - you're screwed anyway here)
2. They can read a user's cookie from malicious JavaScript inserted on your site (i.e. a compromised JS library, or XSS attack that adds JS)

I see! Been working to get this library integrated into an app I'm contributing to. I think I have a better grasp on how it works. Thank you for your informative answer!

[stale]

This issue has been automatically marked as stale because it hasn't seen a recent update. It'll be automatically closed in a few days.