Skip to content
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
@Frondor

Description

@Frondor

I've explained it here: laravel/framework#16310 (comment)

Activity

sisve

sisve commented on Nov 9, 2017

@sisve

From laravel/framework#16310 (comment)

Why would I want the XSRF-TOKEN cookie to be exposed and facilitate XSS attacks? Even if I don't use any of those libraries, that should be configurable in my opinion, and then update the middleware to also take it from the cookie in
https://github.com/laravel/framework/blob/master/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php#L138
like $token = $request->input('_token') ?: ($request->cookie('XSRF-TOKEN') ?: $request->header('X-CSRF-TOKEN'));

Read more about this on : https://stackoverflow.com/questions/21357182/csrf-token-necessary-when-using-stateless-sessionless-authentication#comment53246664_25198454

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)

Remember that all cookies, even the secret ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request.

Frondor

Frondor commented on Nov 9, 2017

@Frondor
Author

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):

I will note that storing your tokens in localStorage or sessionStorage is vulnerable to XSS attacks and that the data can be viewed by scripts on the page - so if you have a compromised script served from a CDN or if there is malicious code in one of your JS libraries, they can steal the token out of those storage places. See: stormpath.com/blog/… I think the most secure approach is to store a JWT + CSRF token in the cookie, and then place your computed JWT with the CSRF token inside it in the request header.

sisve

sisve commented on Nov 9, 2017

@sisve

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

Frondor commented on Nov 9, 2017

@Frondor
Author

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

sisve commented on Nov 9, 2017

@sisve

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.

  1. If we only flag the cookie as httpOnly it has no usage at all since no one is actually using it, and you removed the intended usage of the cookie.
  2. If you change the middleware to use it to validate the request for CSRF protection you break the CSRF protection as I've described.

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

barryvdh commented on Jul 2, 2018

@barryvdh

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

barryvdh commented on Jul 3, 2018

@barryvdh

FYI, it's as easy as setting a property to true/false in 5.7, see the above PR

idhowardgj94

idhowardgj94 commented on Oct 4, 2019

@idhowardgj94

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

# public/.httaccess
<ifModule mod_headers.c>
	Header always edit Set-Cookie: (.*) "$1, httponly"
	Header set X-Content-Type-Options nosniff
	Header always append X-Frame-Options SAMEORIGIN
	Header set X-XSS-Protection "1; mode=block"
</ifModule>

X-Content-Type_options and under are all set.

anyone has any idea why ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @sisve@barryvdh@Frondor@idhowardgj94

        Issue actions

          [Proposal] Allow setting XSRF-TOKEN cookie as httpOnly for XSS attacks · Issue #873 · laravel/ideas