You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I have an idea for a feature request concerning improvement of the CSRF functionality in Laravel. As of the current version, the CSRF token is generated once per session and follows a standard synchronizer token pattern. The token is generated by a random number generator, it is unique for each session and is easily processed by the built-in CSRF middleware. If the token does not match, the server will return a 419 HTTP response status code. This is implemented well and it works without problem. However, this same token is re-used throughout the session and is sent back and forth for every request to the server. This is not necessarily a security flaw, however, the security of this method could potentially be improved. Here is my proposal:
Rotating Tokens
A rotating token logic could be implement to effect each server request which implicitly requires a change to server side data (POST, PUT, DELETE, etc.). In this way, the standard token can be checked and consumed like normal. However, after the token has been checked, the old token is invalidated and a new token is re-generated and saved to the session.
Configuration
Configuration option(s) could be available in the .env file. This variable functions as a global switch to turn on and off the token rotation functionality.
CSRF_TOKEN_ROTATION=true
Asynchronous Calls
Rotating tokens can be a problem for asynchronous calls to the server. Use case:
The form is generated and includes the CSRF token.
Before the form is sent, an asynchronous call is made to the server in the background. This call changes the server-side token for the session.
The form is submitted
The server responds with a 419 http status code, because the old token was invalidated. The form no longer has access to the current token.
This problem can be mitigated through use of of the CSRF middleware, where non-rotating routes can be defined. Below is an example of how this could theoretically look:
File: App/Http/Middleware/VerifyCsrfToken.php
class VerifyCsrfToken extends Middleware
/** * The URIs that should be excluded from CSRF token rotation. * * @var array */
protected $rotationExcept = [
'https://example.com/exclude-me',
'https://example.com/exclude-me-also',
];
}
In this example, the server will exclude the defined routes from the token-rotation functionality. This means, that POST, PUT, DELETE calls will not trigger the rotation logic and the current token will not be invalidated.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Synopsis
Hello, I have an idea for a feature request concerning improvement of the CSRF functionality in Laravel. As of the current version, the CSRF token is generated once per session and follows a standard synchronizer token pattern. The token is generated by a random number generator, it is unique for each session and is easily processed by the built-in CSRF middleware. If the token does not match, the server will return a 419 HTTP response status code. This is implemented well and it works without problem. However, this same token is re-used throughout the session and is sent back and forth for every request to the server. This is not necessarily a security flaw, however, the security of this method could potentially be improved. Here is my proposal:
Rotating Tokens
A rotating token logic could be implement to effect each server request which implicitly requires a change to server side data (POST, PUT, DELETE, etc.). In this way, the standard token can be checked and consumed like normal. However, after the token has been checked, the old token is invalidated and a new token is re-generated and saved to the session.
Configuration
Configuration option(s) could be available in the .env file. This variable functions as a global switch to turn on and off the token rotation functionality.
Asynchronous Calls
Rotating tokens can be a problem for asynchronous calls to the server. Use case:
This problem can be mitigated through use of of the CSRF middleware, where non-rotating routes can be defined. Below is an example of how this could theoretically look:
File: App/Http/Middleware/VerifyCsrfToken.php
In this example, the server will exclude the defined routes from the token-rotation functionality. This means, that POST, PUT, DELETE calls will not trigger the rotation logic and the current token will not be invalidated.
Beta Was this translation helpful? Give feedback.
All reactions