CVE-2021-43846.yml

---
gem: solidus_frontend
cve: 2021-43846
ghsa: h3fg-h5v3-vf8m
url: https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m
title: CSRF forgery protection bypass in solidus_frontend
date: 2022-01-06
description: |
  ### Impact
  CSRF vulnerability that allows a malicious site to add an item to the user's
  cart without their knowledge.

  All `solidus_frontend` versions are affected. If you're using your own
  storefront, please, follow along to make sure you're not affected.

  To reproduce the issue:

  - Pick the id for a variant with available stock. From the rails console:

  ```ruby
  Spree::Variant.in_stock.pluck(:id)
  ```

  Say we pick variant id `2`.

  - Launch your application, for instance,
    on `http://localhost:3000`:

  ```bash
  bin/rails server
  ```

  - Open your browser dev tools.

  - Click on whatever link in your store.

  - Copy the value of the `Cookie` request header sent for the previous request
  from your browser dev tools.

  - Execute the following, using your previously selected variant id and the
  value of the `Cookie` header (notice how it doesn't contain any authentication
  token):

  ```bash
  curl -X POST -d "variant_id=2&quantity=1" -H "Cookie:
  guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8;
  _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D;
  __profilin=p%3Dt" http://localhost:3000/orders/populate
  ```

  - Reload your browser and look at how your cart got updated.

  ### Patches

  Please, upgrade `solidus` to versions `3.1.5`, `3.0.5` or `2.11.14`.

  After upgrading, make sure you read the "Upgrade notes"  section below.

  ### Upgrade notes

  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.

  #### `InvalidAuthenticityToken` errors

  If you're using the `:exception` strategy, it's likely that after upgrading,
  you'll see more `ActionController::InvalidAuthenticityToken` errors popping out
  in your logs. Due to browser-side cache, a form can be re-rendered and sent without
  any attached request cookie (for instance, when re-opening a mobile browser). That
  will cause an authentication error, as the sent token won't match with the one in
  the session (none in this case). That's a known problem in the Rails community (see
  https://github.com/rails/rails/issues/21948), and, at this point, there's no perfect
  solution.

  Any attempt to mitigate the issue should be seen at the application level.
  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 latter is a third-party link. As the information is relevant here, we're going
  to copy it below, but it should be clear that all the credit goes to @kemenaran:

  > # Protecting against request forgery using CRSF tokens
  >
  > ## Context
  >
  > Rails has CSRF protection enabled by default, to protect against POST-based CSRF attacks.
  >
  > To protect from this, Rails stores two copies of a random token (the so-named CSRF token) on each request:
  > - one copy embedded in each HTML page,
  > - another copy in the user session.
  >
  > When performing a POST request, Rails checks that the two copies match – and
  > otherwise denies the request. This protects against an attacker that would
  > generate a form secretly pointing to our website: the attacker can't read
  > the token in the session, and so can't post a form with a valid token.
  >
  > The problem is that, much more often, this has false positives.
  > There are several cases for that, including:
  >
  > 1. The web browser (often mobile) loads a page containing a form, then is
  > closed by the user. Later, when the browser is re-opened, it restores the
  > page from the cache. But the session cookie has expired, and so is not
  > restored – so the copy of the CSRF token stored in the session is missing.
  > When the user submits the form, they get an "InvalidAuthenticityToken"
  > exception.
  >
  > 2. The user attempts to fill a form, and gets an error message (usually in
  > response to a POST request). They close the browser. When the browser is
  > re-opened, it attempts to restore the page. On Chrome this is blocked by the
  > browser, because the browser denies retrying a (probably non-idempotent)
  > POST request. Safari however happily retries the POST request – but without
  > sending any cookies (in an attempt to avoid having unexpected side-effects).
  > So the copy of the CSRF token in the session is missing (because no cookie
  > was sent), and the user get an "InvalidAuthenticityToken" exception.
  >
  > ## Options considered
  >
  > ### Extend the session cookie duration
  >
  > We can configure the session cookie to be valid for a longer time (like 2
  > weeks).
  >
  > Pros:
  > - It solves 1., because when the browser restores the page, the session
  > cookie is still valid.
  >
  > Cons:
  > - Users would be signed-in for a much longer time by default, which has
  > unacceptable security implications.
  > - It doesn't solve 2. (because Safari doesn't send any cookie when restoring
  > a page from a POST request)
  >
  > ### Change the cache parameters
  >
  > We can send a HTTP cache header stating 'Cache-Control: no-store, no-cache'.
  > This instructs the browser to never keep any copy of the page, and to always
  > make a request to the server to restore it.
  >
  > This solution was attempted during a year in production, and solved 1.
  > – but also introduced another type of InvalidAuthenticityToken errors. In
  > that scenario, the user attempts to fill a form, and gets an error message
  > (usually in response to a POST request). They then navigate on another domain (like
  > France Connect), then hit the "Back" button. Crossing back the domain boundary
  > may cause the browser to either block the request or retry an invalid POST request.
  >
  > Pros:
  > - It solves 1., because on relaunch the browser requests a fresh page again
  > (instead of serving it from its cache), thus retrieving a fresh session and
  > a fresh matching CSRF token.
  >
  > Cons:
  > - It doesn't solve 2.
  > - It causes another type of InvalidAuthenticityToken errors.
  >
  > ### Using a null-session strategy
  >
  > We can change the default protect_from_forgery strategy to :null_session.
  > This makes the current request use an empty session for the request duration.
  >
  > Pros:
  > - It kind of solves 1., by redirecting to a "Please sign-in" page
  > when a stale form is submitted.
  >
  > Cons:
  > - The user is asked to sign-in only after filling and submitting the form,
  > losing their time and data
  > - The user will not be redirected to their original page after signing-in
  > - It has potential security implications: as the (potentically malicious)
  > request runs anyway, variables cached by a controller before the Null
  > session is created may allow the form submission to succeed anyway
  > (https://www.veracode.com/blog/managing-appsec/when-rails-protectfromforgery-fails)
  >
  > ### Using a reset-session strategy
  >
  > We can change the default protect_from_forgery strategy to :reset_session.
  > This clears the user session permanently, logging them out until they log in
  > again.
  >
  > Pros:
  > - It kind of solves 1., by redirecting to a "Please sign-in" page when a
  > stale form is submitted.
  >
  > Cons:
  > - A forgery error in a browser tab will disconnect the user in all its open
  > tabs
  > - It has potential security implications: as the (potentically malicious)
  > request runs anyway, variables cached by a controller before the Null session
  > is created may allow the form submission to succeed anyway
  > (https://www.veracode.com/blog/managing-appsec/when-rails-protectfromforgery-fails)
  > - It allows an attacker to disconnect an user on demand, which is not only
  > inconvenient, but also has security implication (the attacker could then log
  > the user on it's own attacker account, pretending to be the user account)
  >
  > ### Redirect to login form
  >
  > When a forgery error occurs, we can instead redirect to the login form.
  >
  > Pros:
  > - It kind of solves 1., by redirecting to a "Please sign-in" page when a
  > stale form is submitted (but the user data is lost).
  > - It kind of solves 2., by redirecting to a "Please sign-in" page when a
  > previously POSTed form is reloaded.
  >
  > Cons:
  > - Not all forms require authentication – so for
  > public forms there is no point redirecting to the login form.
  > - The user will not be redirected to their original page after signing-in
  > (because setting the redirect path is a state-changing action, and it is
  > dangerous to let an unauthorized request changing the state – an attacker
  > could control the path where an user is automatically redirected to.)
  > - The implementation is finicky, and may introduce security errors.
  > For instance, a naive implementation that catches the exception and
  > redirect_to the sign-in page will prevent Devise from running a cleanup code
  > – which means the user will still be logged, and the CSRF protection is
  > bypassed. However a well-tested implementation that lets Devise code run
  > should avoid these pittfalls.
  >
  > ### Using a long-lived cookie for CSRF tokens
  >
  > Instead of storing the CSRF token in the session cookie (which is deleted
  > when the browser is closed), we can instead store it in a longer-lived
  > cookie. For this we need to patch Rails.
  >
  > Pros:
  > - It solves 1., because when the user submits a stale form, even if the
  > session cookie because stale, the long-lived CSRF cookie is still valid.
  >
  > Cons:
  > - It doesn't solve 2., because when Safari retries a POST request, it sends
  > none of the cookies (not even long-lived ones).
  > - Patching Rails may introduce security issues (now or in the future)

  #### Broken behavior due to session expiration + template cache

  Although pretty unlikely, you should make sure that your current setup for
  cache/session expiration is compatible. The upgrade can break the addition
  of products to the cart if both:

  - The "Add to cart" form is being cached (usually along with the variant
  information).

  - A user session is reset at every or every few requests.

  The token validation depends on the issuing and consuming sessions
  being the same. If a product page is cached with the token in it, it can
  become stale on a subsequent rendering if the session changes.

  To check that you're safe, after having upgraded locally, go through the
  following steps:

  - Enable cache on dev mode:

  ```bash
  bin/rails dev:cache
  ```

  - Visit the page for a variant with stock.

  - Reload that page several times.

  - Click on the "Add to cart"  button.

  - Remember to rerun `bin/rails dev:cache` to turn off cache again.

  No error or session reset should happen.

  Otherwise, you can try with:

  - Revisiting how your session gets expired.
  - Changing the caching strategy to exclude the token.

  #### Using weaker CSRF protection strategies

  It's also important to understand that a complete fix will only be in place
  when using the `:exception` forgery protection strategy. The
  `solidus_frontend` engine can't do pretty much anything otherwise. Using
  weaker CSRF strategies should be an informed and limited decision made by the
  application team. After the upgrade:

  - An app using `:null_session` should also be safe, but there will be side
  effects. That strategy runs with a null object session. As such, no order and
  no user is found on it. A new `cart` state order is created in the database,
  associated with no user. Next time the user visits the site, they won't find
  any difference in its cart state.

  - An app using `:reset_session` is not entirely safe. That strategy resets the
  session. That means that registered users will be logged out. Next time a user
  visits, they'll see the cart with the items added during the CSRF attack,
  although it won't be associated with their account in the case of registered
  users.

  #### Reversing the update

  If you still want to deploy the upgraded version before changing your
  application code (if the latter is needed), you can add the following
  workaround to your `config/application.rb` (however, take into account that
  you'll keep being vulnerable):

  ```ruby
  config.after_initialize do
    Spree::OrdersController.skip_before_action :verify_authenticity_token, only:
      [:populate]
  end
  ```

  ### Workarounds

  If an upgrade is not an option, you can work around the issue by adding the
  following to `config/application.rb`:

  ```ruby
  config.after_initialize do
    Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym,
      only: [:populate]
  end
  ```

  However, go through the same safety check detailed on "Upgrade notes" above.

  ### References

  - [CSRF on the Rails guides](https://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf)
  - [How CSRF tokens are generated and validated on Rails](https://medium.com/rubyinside/a-deep-dive-into-csrf-protection-in-rails-19fa0a42c0ef)
  - [Solidus security](https://solidus.io/security/)
cvss_v3: 5.3
patched_versions:
  - ">= 3.1.5"
  - "~> 3.0.5"
  - "~> 2.11.14"
related:
  url:
    - https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81
    - https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6