419 Error with POST requests

[jbardnz]

Hi there,

I have added this package to my Laravel app, I am also using Intertia.js on the frontend. Everytime I make a post request I am getting a 419 unknown status error being returned. It looks like the X-XSRF-TOKEN which is usually automatically added to every post request isn't being sent when I am using this package, any idea why that might be?

Thanks

[aidantwoods]

Usually something like this would be set on the request made by the client (rather than the response from your app), is that correct in this instance? SecureHeaders shouldn't be modifying any headers contained in client requests.

Assuming the above is correct, do you know if the CSRF token is delivered in a response header prior to the POST request being made? I'm wondering if somehow the token has been malformed before it reaches the client.

[jbardnz]

Okay so it looks like I was wrong about the cause of this issue. I realised the X-XSRF-TOKEN as it was being set to httpOnly. I have fixed that issue and can now see the token is sent in the request however I still get the same 419 error as soon as I enable the \MikeFrancis\LaravelSecureHeaders\ApplySecureHeaders::class middleware.

Here is a screenshot of my request from Chrome dev tools, you can see that the session cookies/XSRF tokens are being sent correctly:

[aidantwoods]

Have you got an example of a request that succeeds for comparison?

[jbardnz]

Yes I do, here is a successful login request. Everything is exactly the same as the previous request expect the middleware is disabled:

[aidantwoods]

Quick look (I am on mobile though) does look like these are the same.

Do you by any chance have error reporting (in PHP) turned on. I've noticed you have a CSP that has things like 'unsafe-inline' in, and the base SecureHeaders package will critique this using PHPs error reporting level. (Possible this early output might cause problems on responses that aren't designed to send any content/weren't finished setting headers).

[jbardnz]

I'm wondering if this could be the issue, in my Laravel session.php file I have disabled http_only. However when I check Chrome I can see the XSRF-TOKEN still has the HttpOnly flag, this would stop Axios being able to access the token:

Is there a way to stop the HttpOnly flag being applied to this cookie?

[aidantwoods]

SecureHeaders will try to protect some cookies automatically as documented in auto#auto_cookie_httponly and protectedCookie. This is tuneable, but from a quick check of the source code in this package I don't think there is a mapping for these settings yet.

@mikefrancis probably the config could accept an array of cookie names/substrings to allow tuning this? E.g. (probably most of these optional with empty defaults)

'protectedCookies' => [
    'add' => [
        'names' => [...],
        'substrings' => [...],
    ],
    'remove' => [
        'names' => [...],
        'substrings' => [...],
    ]
]

@jbardnz if you manually unset the httpOnly flag in your browser (but with the middleware still enabled) does the problem go away?

[jbardnz]

@aidantwoods I just edited the cookie manually and my problem is fixed if I switch off HttpOnly.

[mxkxf]

@aidantwoods Sounds good! Will take a look tonight.

[mxkxf]

@jbardnz Sorry about the delay here, I've made a pull request ☝️ for looking into this but with everything that's happening I'm struggling to find time to work on this.

Having some problems attaching a cookie to a new Symfony Request instance so it's slow progress.

If you want to pick it up - please do. Can't really commit to when I'll be able to get this sorted.

[pfaffenrodt]

I temporary disabled it

app()->bind(SecureHeaders::class, function () {
            $secureHeaders = new SecureHeaders();
            $allButNotHttpOnly = ~SecureHeaders::AUTO_COOKIE_HTTPONLY;
            $secureHeaders->auto($allButNotHttpOnly);

            return $secureHeaders;
        });