Headline
CVE-2021-43846: Protect `Spree::OrdersController#populate` against CSRF attacks · solidusio/solidus@4d17cac
solidus_frontend is the cart and storefront for the Solidus e-commerce project. Versions of solidus_frontend prior to 3.1.5, 3.0.5, and 2.11.14 contain a cross-site request forgery (CSRF) vulnerability that allows a malicious site to add an item to the user’s cart without their knowledge. Versions 3.1.5, 3.0.5, and 2.11.14 contain a patch for this issue. The patch adds CSRF token verification to the “Add to cart” action. Adding forgery protection to a form that missed it can have some side effects. Other CSRF protection strategies as well as a workaround involving modifcation to config/application.rb` are available. More details on these mitigations are available in the GitHub Security Advisory.
Permalink
Browse files
Protect Spree::OrdersController#populate against CSRF attacks
See GHSA-h3fg-h5v3-vf8m for all the details.
Some time ago, all order actions were left out of CSRF protection (see 95ea570). The reason given was that the authentication token got stale after the second rendering because the product page is cached. That was limited to `#populate` in cb79754 (see also spree/spree#5601).
However, those assumptions are not correct. Although the authenticity token changes at every request, that doesn’t mean that the old ones are no longer valid. The variation comes from a one-time pad added to a session-dependant token (and meant to avoid timing attacks). However, before validation, that one-time pad is removed. That means the token remains valid as long as the session has not been reset. Think about submitting a form from one browser tab after opening another with the same URL. Even if both tokens differ, the submission from the first tab will still be valid. You can read https://medium.com/rubyinside/a-deep-dive-into-csrf-protection-in-rails-19fa0a42c0ef for an in-deep understanding.
The initial confusion could come because of rails/rails#21948. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie. That will cause an authentication error, as the sent token won’t match with the one in the session (none in this case). There’s no perfect solution for that, and all partial fixes should be seen at the application level. From our side, we must provide a safe default. For an excellent survey of all the available options, take a look at https://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md. The information given in that link is third-party but it’s very relevant here. For that reason we’ve copied it in the security advisory (see link above), but all the credit goes to @kemenaran.
- Loading branch information
Showing with 0 additions and 1 deletion.
- +0 −1 frontend/app/controllers/spree/orders_controller.rb