Where are xsrf tokens stored on a server side?

@OussamaMater yes, thats where i checked it out. Now I even changed xsrf token on client side and even deleted it, but there are no errors, everything just works fine. Why does it behave like that?

@DavidBuchukuri after deleting the token have made any post requests? is the user still authenticated? and you have not touched the VerifyCsrfToken middleware right?

This token (csrf token) is used to verify that the authenticated user is the person actually making the requests to the application.

Reference: https://laravel.com/docs/9.x/csrf#preventing-csrf-requests

So if you played around with a guest user, nothing will happen obviously.

@OussamaMater not quite true. CSRF tokens apply to all form POST submissions, nothing to do with whether you are authenticated or not.

@Snapey I asked if he made post requests above, but from what I understand he played with a fresh laravel app deleting the tokens, you can't see any errors if you just delete the csrf tokens and refresh (which is a GET request as you do know) the application while being a guest user.

@OussamaMater I figured that laravel sets a new xsrf on each request, so deleting or changing a cookie won't do much, but still, I can't find the place where that token is stored on a server side, I'll take a look at the source code, hopefully i'll figure it out :-;

@DavidBuchukuri Its held in session for the user

here's the code that checks it;

    /**
     * Determine if the session and input CSRF tokens match.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return bool
     */
    protected function tokensMatch($request)
    {
        $token = $this->getTokenFromRequest($request);

        return is_string($request->session()->token()) &&
               is_string($token) &&
               hash_equals($request->session()->token(), $token);
    }

If you install barryvdh/laravel-debugbar, you can see it in the session variables as _token

@DavidBuchukuri yes of course, that's the point of csrf tokens, if you have one static token that does not change, an attacker might use it in his malicious site by adding it as a normal form input (that will be sent with the request once you click a button or whatever was set for you), the token needs to be random and unpredictable to prevent the csrf attack.

As I mentionned above, by default, Laravel has the session driver set to file, so you can go to the directory storage/framework/sessions and check them there.

@OussamaMater ohh my bad, so there is 1 token in a session, and I assumed that was an id of the current session, but when i compared values from cookies, occures it's actually a xsrf token, and session id is a file's name where a session data is stored

@DavidBuchukuri yes the token is set with the user's session, and all this is done to prevent the csrf attack, which if you want to learn more about I highly recommend watching this video, it discuss the topic in depth

• https://www.youtube.com/watch?v=eWEgUcHPle0

Edit: if the whole process is still a bit ambiguous, check the answer to this question

• https://stackoverflow.com/questions/45012015/how-to-validate-csrf-tokens?fbclid=IwAR0W4mX0g5rv09caJYv-u4zuHbf1__Hs2UiX_XGlF-agEeY-rIYGEZ7406E

@DavidBuchukuri and yours was the best answer?

@OussamaMater thanks for that, the part which got me confused was that, I asummed _token inside a session file was a session id. I didn't pay attention to a file name itself. Couldn't have thought that, laravel stored session id by just naming files as session ids. in my opinion, it would be more intuitive if both xsrf token and session id were stored inside a session file.

@DavidBuchukuri then how would the framework know which file to look in to check if the user's sessionID is found?

When session storage is DB, the sessionID is a column on the table.

@Snapey that makes sense, thanks for pointing that out

@DavidBuchukuri Glad it now makes sense!

@sr57 +1 to this.