[Security] Do not try to clear CSRF on stateless request #54742
Conversation
d71784c to
3d4b434
Compare
...mfony/Bundle/SecurityBundle/Tests/Functional/app/LogoutWithoutSessionInvalidation/config.yml
Show resolved
Hide resolved
|
|
||
| if ( | ||
| $this->csrfTokenStorage instanceof SessionTokenStorage | ||
| && ($request->attributes->getBoolean('_stateless') || !$request->hasPreviousSession()) |
There was a problem hiding this comment.
But why do we have a previous request in the first place in your situation?
If there is a previous session, we should clean the session even of this contradicts the stateless flag, or we might create a security issue, or?
There was a problem hiding this comment.
Our API and website are sharing the same domain.
API is accessible from domain.com/api/
The user can be authenticated on the website using session and also using JWT on the API on the same device.
When the user already has a session on the website and try to logout from the API, it results in this log message.
(On the API we use the logout endpoint to delete refresh tokens of the user in our db)
Because the logout listener is only checking if the request ha a previous session when all other listeners also check if the request is stateless.
There was a problem hiding this comment.
BTW, this is also how works others logout listeners.
If the user logout on a stateless request (and also has a session on the same device), his session is not cleared.
So we should also clear the CSRF token too on statleless requests.
There was a problem hiding this comment.
is the API using the same firewall than the website ?
There was a problem hiding this comment.
No, we had a separated stateless firewall for ^/api routes.
I was not able to find how to reproduce that issue myself by using our mobile app, but I was suspecting the mobile app to call some website routes in some rare scenarios.
There was a problem hiding this comment.
then I think the right fix would be that the CSRF clearing logout listener should be registered only for stateful firewalls (note that I'm not talking about the flag on the request here, but on the firewall config).
|
@chalasr @nicolas-grekas Any chance this could be merged? |
|
|
|
@chalasr @nicolas-grekas any update? @xabbuh You recently approved a similar PR, maybe you can review this one too? |
|
(note that #57372 has been reverted recently) |
Maybe @VincentLanglet can provide more context about the revert of that PR, but it looks like the PR was not totally reverted, only 1 line from what I see
This was @chalasr suggestion from a previous PR (#51320 (comment)) to use the |
not anymore, this was all reverted recently |
Sorry for the (now) bad suggestion, we've been reviewing and clarifying the scope of this attribute lately. The statelessness of a firewall can be check using |
cc15f6d to
1be07ff
Compare
|
Thank for the clarification. I tried to updated my PR. But |
No. |
|
Please keep in mind that sateless firewall !== stateless request. I can have stateful requests behind a stateless firewall. And I can have stateless requests without any firewall. |
|
I re created my original PR here: #58082 |
| $request = new Request(); | ||
| $request->setSession($session); | ||
| $request->cookies->set($session->getName(), 'previous_session'); | ||
| $request->attributes->set('_stateless', true); |
There was a problem hiding this comment.
let's remove this since it's not related anymore, isn't it?
|
|
||
| public function __construct(ClearableTokenStorageInterface $csrfTokenStorage) |
There was a problem hiding this comment.
adding an argument is a BC break, let's make it nullable?
@nicolas-grekas I can fix your review suggestions, but what about this? |
|
Could we augment the LogoutEvent with an isStatelessFirewall method? |
|
Let me close here as another approach has been hinted. |
In my application, I am getting many logs
Session was used while the request was declared stateless.triggered by users logout on our API.We should not try to clear CSRF on stateless sessions.
Similar to #51350