Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve CSRF protection scheme to accommodate more web/mobile app scenarios #898

Open
alexweissman opened this issue Sep 30, 2018 · 1 comment
Labels
architecture Related to the framework architecture REST API API standard security Framework security issue up-for-grabs Not assigned yet
Milestone

Comments

@alexweissman
Copy link
Member

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:

  1. Requests aren't always made from a web page. In this case a separate request needs to be made to retrieve the CSRF token.
  2. 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

@alexweissman alexweissman added security Framework security issue REST API API standard architecture Related to the framework architecture labels Sep 30, 2018
@lcharette
Copy link
Member

Possibly related to #706

@lcharette lcharette added the up-for-grabs Not assigned yet label Jun 27, 2019
@lcharette lcharette added this to the 6.0.0 milestone Nov 25, 2023
@lcharette lcharette moved this from Todo 6.0 to Not Started in UserFrosting Task Planner Apr 13, 2024
@lcharette lcharette moved this from Not Started to References in UserFrosting Task Planner Apr 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture Related to the framework architecture REST API API standard security Framework security issue up-for-grabs Not assigned yet
Projects
Status: References
Development

No branches or pull requests

2 participants