Closed robojones closed 3 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.
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.
Thanks for clarifying that @elithrar 👍
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:
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.
@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 theOrigin
header is also included for all requests whose method is neitherGET
norHEAD
.
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?
@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
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.
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
orReferer
header?Thanks in advance for any input :smiley: