make token invalidation optional

[linusheske]

Q	A
Documentation	no
Bugfix	no
BC Break	no
New Feature	yes
RFC	no
QA	no

Description

In my opinion, invalidating a csrf token should be optional. The token is currently invalidated in the src/SessionCsrfGuard::validateToken method with each call. This is not always the desired behaviour. Especially when using the libary in legacy Applications.

References:
https://security.stackexchange.com/questions/22903/why-refresh-csrf-token-per-form-request/22936

For the reasons already discussed, it is not necessary to generate a new token per request. It brings almost zero security advantage, and it costs you in terms of usability: with only one token valid at once, the user will not be able to navigate the webapp normally. For example if they hit the 'back' button and submit the form with new values, the submission will fail, and likely greet them with some hostile error message. If they try to open a resource in a second tab, they'll find the session randomly breaks in one or both tabs.

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern

CSRF tokens should be generated on the server-side. They can be generated once per user session or for each request. Per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal. However, this may result in usability concerns. For example, the "Back" button browser capability is often hindered as the previous page may contain a token that is no longer valid. Interaction with this previous page will result in a CSRF false positive security event at the server. In per-session token implementation after initial generation of token, the value is stored in the session and is used for each subsequent request until the session expires.

[Ocramius]

Seems OK-ish from my PoV: token could be invalidated after usage.

There is still a BC break though: currently, the behavior invalidates the token each time, which means that mezzio-csrf is precisely able to prevent form submit in some cases. That may be seen as a UX issue (like in this ticket) or as a feature (preventing usage of the same form on multiple browser tabs, for example), depending on PoV.

If this middleware is used only for preventing third-party XSS, then IMO Same-Site headers are a better alternative to the whole component 🤔

[Ocramius]

This interface change is still a BC break though.