This repository was archived by the owner on Jul 16, 2021. It is now read-only.
This repository was archived by the owner on Jul 16, 2021. It is now read-only.
[Proposal] Allow setting XSRF-TOKEN cookie as httpOnly for XSS attacks #873
Closed
Description
I've explained it here: laravel/framework#16310 (comment)
Activity
sisve commentedon Nov 9, 2017
From laravel/framework#16310 (comment)
I believe you've misunderstood what CSRF protects against and how it works. Your suggestion would remove the CSRF protection completely. What you describe is the first example in the list of "Prevention measures that do NOT work" at https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
Frondor commentedon Nov 9, 2017
How is it removing the CSRF protection? Even if the cookie is
httpOnly
flagged, the app is still checking the token in the code example I've provided.You seem to be confused as well, probably I didn't explain myself.
I'm talking about XSS attacks, if someone managed to inject js code in your site, he has access to that CSRF token, and your app is now vulnerable to a CSRF attack as well.
Read the SO comment I linked (it's about JWT but shares the same PoV):
sisve commentedon Nov 9, 2017
The browser will submit the XSRF cookie in every request; and changing the middleware to read this cookie means it will validate and accept every request no matter where the request really originated.
Frondor commentedon Nov 9, 2017
I think you're missing the point about how
httpOnly
flag works,The middleware is already setting that cookie for you. But it isn't flagged as a http-only cookie, meaning it's accessible from javascript.
Yeah, it isn't top notch protection but protects the CSRF token from malicious code in your front-end.
sisve commentedon Nov 9, 2017
The cookie is currently not used by the CSRF protection for validation, it is only set. The client-side javascript is meant to read it and set it in the payload in the responses.
Regarding the linked Stack Overflow issue; I don't see how it is relevant. The question is about stateless/sessionless authentication, but Laravel comes out-of-the-box with session support enabled. The comment you linked is talking about a compromised cdn, but if that is really the attack vector you want to protect yourself against, why not 1) host the scripts on your own cdn, or 2) use subresource integrity (SRI) where you hash the scripts?
barryvdh commentedon Jul 2, 2018
I understand the confusion, but also the need for this httpOnly cookie. But it is a bit confusing, I've had two separate security auditors complain about this httpOnly cookie.
It's easy to remove by overriding the method, but perhaps it should be opt-in or opt-out..
barryvdh commentedon Jul 3, 2018
FYI, it's as easy as setting a property to true/false in 5.7, see the above PR
idhowardgj94 commentedon Oct 4, 2019
I agree with @barryvdh
I understand that set XSRF-TOKEN cookie without httponly is necessary when I need to use javascript library like jquery ajax, axio.
but I use laravel 5.5, there is a solution already build in example code that using meta tag to pass csrf-token to javascript. so there is no reason to expose XSRF-TOKEN without httponly flag.
btw, I try to modify header use apache.
but it's not working, and only not working in 'set-cookie' part
X-Content-Type_options and under are all set.
anyone has any idea why ?