CVE-2021-43846

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.

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.

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:

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

  Say we pick variant id 2.

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

  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):

  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…

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.

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.

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:

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

  Say we pick variant id 2.

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

  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):

  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…