-
-
Notifications
You must be signed in to change notification settings - Fork 363
Open
Labels
REST APIAPI standardAPI standardarchitectureRelated to the framework architectureRelated to the framework architecturesecurityFramework security issueFramework security issueup-for-grabsNot assigned yetNot assigned yet
Milestone
Description
Right now CSRF protection is implemented solely by using a CSRF token associated with the client's PHP session. The client must retrieve the token from a web page, either from an embedded form element, or from the global Javascript site variable, and then send it to the server in the request body. The server then checks it against the token stored in the client's session.
This can be a problem for two reasons:
- Requests aren't always made from a web page. In this case a separate request needs to be made to retrieve the CSRF token.
- If the CSRF token is stored in the PHP session, it is lost once the PHP session expires. If this happens while a user is in the middle of filling out a form, they will get a CSRF expiration error and be asked to reload their page (and probably lose all of their form data).
One alternative, or supplemental method we could include, is simply checking for the X-Requested-With: XMLHttpRequest in the request for AJAX requests. See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Protecting_REST_Services:_Use_of_Custom_Request_Headers
amivag
Metadata
Metadata
Assignees
Labels
REST APIAPI standardAPI standardarchitectureRelated to the framework architectureRelated to the framework architecturesecurityFramework security issueFramework security issueup-for-grabsNot assigned yetNot assigned yet
Type
Projects
Status
References