gorilla / csrf

Package gorilla/csrf provides Cross Site Request Forgery (CSRF) prevention middleware for Go web applications & services 🔒
https://gorilla.github.io
BSD 3-Clause "New" or "Revised" License
1.06k stars 154 forks source link

Does gorilla-csrf really provide more security? #143

Closed robojones closed 3 years ago

robojones commented 4 years ago

Describe the problem you're having I am trying to understand what problem gorilla-csrf solves. As far as I understand CSRF is when an attacker executes cross site requests when I visit their website. For example, when I am logged into an online shop, the attacker site could try to send an order form without my knowledge. I understand that this library makes that impossible for them but wouldn't it be easier if the online shop just verified the Origin or Referer header?

Thanks in advance for any input :smiley:

elithrar commented 4 years ago

Please take a look at https://owasp.org/www-community/attacks/csrf and https://portswigger.net/web-security/csrf

Validating the Origin / Referer headers - which may not be present in all cases, and certainly not for a cross-domain POST over HTTPS - does not protect you from CSRF attacks.

stale[bot] commented 4 years ago

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.

robojones commented 4 years ago

Thanks for clarifying that @elithrar 👍

steebchen commented 4 years ago

I'm not sure if that's true for what @robojones suggests. If your API just accepts POST requests, it looks like checking for the origin header seems to be sufficient in 2020 onward; assuming you use it in combination with SameSite=Strict cookies.

Also see:

https://security.stackexchange.com/questions/158045/is-checking-the-referer-and-origin-headers-enough-to-prevent-csrf-provided-that

I'm not saying CSRF is not useful anymore, I just think that SameSite=Strict plus checking the origin header is probably sufficient for most people, and doesn't need any storage on the server.

philipjscott commented 3 years ago

@steebchen why is using SameSite=Strict cookies a requirement? Isn't reading the Origin header enough?

@elithrar regarding:

which may not be present in all cases, and certainly not for a cross-domain POST over HTTPS

According to https://fetch.spec.whatwg.org/#cors-request,

A CORS request is an HTTP request that includes an Origin header. It cannot be reliably identified as participating in the CORS protocol as the Origin header is also included for all requests whose method is neither GET nor HEAD.

Doesn't that mean the Origin header is sent for all cross-domain POSTs over HTTPS? As for GET and HEAD, as long as you ensure those methods don't mutate state, you should be fine to skip the origin check, right?

robojones commented 3 years ago

@ScottyFillups

why is using SameSite=Strict cookies a requirement? Isn't reading the Origin header enough?

SameSite=Strict on cookies just provides an additional layer of security. I did look into this and checking the Origin header should be sufficient to prevent CSRF.

Doesn't that mean the Origin header is sent for all cross-domain POSTs over HTTPS? As for GET and HEAD, as long as you ensure those methods don't mutate state, you should be fine to skip the origin check, right?

Yup

stale[bot] commented 3 years ago

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.