cvelistv5 - cve-2021-43846

CVE-2021-43846 (GCVE-0-2021-43846)

Vulnerability from cvelistv5 – Published: 2021-12-20 21:30 – Updated: 2024-08-04 04:10

Summary

`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.

Severity ?

5.3 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

CWE

CWE-352 - Cross-Site Request Forgery (CSRF)

Assigner

GitHub_M

References

URL

	Vendor	Product	Version
	solidusio	solidus	Affected: >= 3.1.0, < 3.1.5 Affected: >= 3.0.0, < 3.0.5 Affected: < 2.11.14

GHSA-H3FG-H5V3-VF8M

Vulnerability from github – Published: 2022-01-06 18:33 – Updated: 2023-05-04 19:59

Summary

CSRF forgery protection bypass in solidus_frontend

Details

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:

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.

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

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:

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

For more information

If you have any questions or comments about this advisory: * Open an issue or a discussion in Solidus. * Email us at security@solidus.io * Contact the core team on Slack

Severity ?

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "solidus_frontend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "solidus_frontend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "solidus_frontend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-43846"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-01-04T20:24:16Z",
    "nvd_published_at": "2021-12-20T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nCSRF vulnerability that allows a malicious site to add an item to the user\u0027s cart without their knowledge.\n\nAll `solidus_frontend` versions are affected. If you\u0027re using your own storefront, please, follow along to make sure you\u0027re not affected.\n\nTo reproduce the issue:\n\n- Pick the id for a variant with available stock. From the rails console:\n\n  ```ruby\n  Spree::Variant.in_stock.pluck(:id)\n  ```\n\n  Say we pick variant id `2`.\n\n- Launch your application, for instance, on `http://localhost:3000`:\n\n  ```bash\n  bin/rails server\n  ```\n\n- Open your browser dev tools.\n\n- Click on whatever link in your store.\n\n- Copy the value of the `Cookie` request header sent for the previous request from your browser dev tools.\n\n- Execute the following, using your previously selected variant id and the value of the `Cookie` header (notice how it doesn\u0027t contain any authentication token):\n\n  ```bash\n  curl -X POST -d \"variant_id=2\u0026quantity=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\n  ```\n\n- Reload your browser and look at how your cart got updated.\n\n### Patches\n\nPlease, upgrade `solidus` to versions `3.1.5`, `3.0.5` or `2.11.14`.\n\nAfter upgrading, make sure you read the \"Upgrade notes\"  section below.\n\n### Upgrade notes\n\nThe 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.\n\n#### `InvalidAuthenticityToken` errors\n\nIf you\u0027re using the `:exception` strategy, it\u0027s likely that after upgrading, you\u0027ll 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\u0027t match with the one in the session (none in this case). That\u0027s a known problem in the Rails community (see https://github.com/rails/rails/issues/21948), and, at this point, there\u0027s no perfect solution.\n\nAny 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\u0027re going to copy it below, but it should be clear that all the credit goes to @kemenaran:\n\n\u003e # Protecting against request forgery using CRSF tokens\n\u003e \n\u003e ## Context\n\u003e \n\u003e Rails has CSRF protection enabled by default, to protect against POST-based CSRF attacks.\n\u003e \n\u003e To protect from this, Rails stores two copies of a random token (the so-named CSRF token) on each request:\n\u003e - one copy embedded in each HTML page,\n\u003e - another copy in the user session.\n\u003e \n\u003e When performing a POST request, Rails checks that the two copies match \u2013 and otherwise denies the request. This protects against an attacker that would generate a form secretly pointing to our website: the attacker can\u0027t read the token in the session, and so can\u0027t post a form with a valid token.\n\u003e \n\u003e The problem is that, much more often, this has false positives. There are several cases for that, including:\n\u003e \n\u003e 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 \u2013 so the copy of the CSRF token stored in the session is missing. When the user submits the form, they get an \"InvalidAuthenticityToken\" exception.\n\u003e \n\u003e 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 \u2013 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.\n\u003e \n\u003e ## Options considered\n\u003e \n\u003e ### Extend the session cookie duration\n\u003e \n\u003e We can configure the session cookie to be valid for a longer time (like 2 weeks).\n\u003e \n\u003e Pros:\n\u003e - It solves 1., because when the browser restores the page, the session cookie is still valid.\n\u003e \n\u003e Cons:\n\u003e - Users would be signed-in for a much longer time by default, which has unacceptable security implications.\n\u003e - It doesn\u0027t solve 2. (because Safari doesn\u0027t send any cookie when restoring a page from a POST request)\n\u003e \n\u003e ### Change the cache parameters\n\u003e \n\u003e We can send a HTTP cache header stating \u0027Cache-Control: no-store, no-cache\u0027. This instructs the browser to never keep any copy of the page, and to always make a request to the server to restore it.\n\u003e \n\u003e This solution was attempted during a year in production, and solved 1. \u2013 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.\n\u003e \n\u003e Pros:\n\u003e - 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.\n\u003e \n\u003e Cons:\n\u003e - It doesn\u0027t solve 2.\n\u003e - It causes another type of InvalidAuthenticityToken errors.\n\u003e \n\u003e ### Using a null-session strategy\n\u003e \n\u003e 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.\n\u003e \n\u003e Pros:\n\u003e - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a stale form is submitted.\n\u003e \n\u003e Cons:\n\u003e - The user is asked to sign-in only after filling and submitting the form, losing their time and data\n\u003e - The user will not be redirected to their original page after signing-in\n\u003e - 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)\n\u003e \n\u003e ### Using a reset-session strategy\n\u003e \n\u003e 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.\n\u003e \n\u003e Pros: \n\u003e - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a stale form is submitted.\n\u003e \n\u003e Cons:\n\u003e - A forgery error in a browser tab will disconnect the user in all its open tabs\n\u003e - 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)\n\u003e - 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\u0027s own attacker account, pretending to be the user account)\n\u003e \n\u003e ### Redirect to login form\n\u003e \n\u003e When a forgery error occurs, we can instead redirect to the login form.\n\u003e \n\u003e Pros:\n\u003e - 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).\n\u003e - It kind of solves 2., by redirecting to a \"Please sign-in\" page when a previously POSTed form is reloaded.\n\u003e \n\u003e Cons:\n\u003e - Not all forms require authentication \u2013 so for public forms there is no point redirecting to the login form. \n\u003e - 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 \u2013 an attacker could control the path where an user is automatically redirected to.)\n\u003e - 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 \u2013 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.\n\u003e \n\u003e ### Using a long-lived cookie for CSRF tokens\n\u003e \n\u003e 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.\n\u003e \n\u003e Pros:\n\u003e - 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.\n\u003e \n\u003e Cons:\n\u003e - It doesn\u0027t solve 2., because when Safari retries a POST request, it sends none of the cookies (not even long-lived ones).\n\u003e - Patching Rails may introduce security issues (now or in the future)\n\n#### Broken behavior due to session expiration + template cache\n\nAlthough 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:\n\n- The \"Add to cart\" form is being cached (usually along with the variant information).\n\n- A user session is reset at every or every few requests.\n\nThe 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.\n\nTo check that you\u0027re safe, after having upgraded locally, go through the following steps:\n\n- Enable cache on dev mode:\n\n  ```bash\n  bin/rails dev:cache\n  ```\n\n- Visit the page for a variant with stock.\n\n- Reload that page several times.\n\n- Click on the \"Add to cart\"  button.\n\n- Remember to rerun `bin/rails dev:cache` to turn off cache again.\n\nNo error or session reset should happen.\n\nOtherwise, you can try with:\n\n- Revisiting how your session gets expired.\n- Changing the caching strategy to exclude the token.\n\n#### Using weaker CSRF protection strategies\n\nIt\u0027s 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\u0027t do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:\n\n- 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\u0027t find any difference in its cart state.\n\n- 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\u0027ll see the cart with the items added during the CSRF attack, although it won\u0027t be associated with their account in the case of registered users.\n\n#### Reversing the update\n\nIf 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\u0027ll keep being vulnerable):\n\n```ruby\nconfig.after_initialize do\n  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]\nend\n```\n\n### Workarounds\n\nIf an upgrade is not an option, you can work around the issue by adding the following to `config/application.rb`:\n\n```ruby\nconfig.after_initialize do\n  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]\nend\n```\n\nHowever, go through the same safety check detailed on \"Upgrade notes\" above.\n\n### References\n\n- [CSRF on the Rails guides](https://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf)\n- [How CSRF tokens are generated and validated on Rails](https://medium.com/rubyinside/a-deep-dive-into-csrf-protection-in-rails-19fa0a42c0ef)\n- [Solidus security](https://solidus.io/security/)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an [issue](https://github.com/solidusio/solidus/issues) or a [discussion](https://github.com/solidusio/solidus/discussions) in Solidus.\n* Email us at [security@solidus.io](mailto:security@soliidus.io)\n* Contact the core team on [Slack](http://slack.solidus.io/)\n",
  "id": "GHSA-h3fg-h5v3-vf8m",
  "modified": "2023-05-04T19:59:15Z",
  "published": "2022-01-06T18:33:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43846"
    },
    {
      "type": "WEB",
      "url": "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81"
    },
    {
      "type": "WEB",
      "url": "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/solidus_frontend/CVE-2021-43846.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/solidusio/solidus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CSRF forgery protection bypass in solidus_frontend"
}

GSD-2021-43846

Vulnerability from gsd - Updated: 2022-01-06 00:00

Details

### 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/)

Aliases

CVE-2021-43846

JSON

To clipboard

{
  "GSD": {
    "alias": "CVE-2021-43846",
    "description": "`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\u0027s 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.",
    "id": "GSD-2021-43846"
  },
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "affected": [
        {
          "package": {
            "ecosystem": "RubyGems",
            "name": "solidus_frontend",
            "purl": "pkg:gem/solidus_frontend"
          }
        }
      ],
      "aliases": [
        "CVE-2021-43846",
        "GHSA-h3fg-h5v3-vf8m"
      ],
      "details": "### Impact\nCSRF vulnerability that allows a malicious site to add an item to the user\u0027s\ncart without their knowledge.\n\nAll `solidus_frontend` versions are affected. If you\u0027re using your own\nstorefront, please, follow along to make sure you\u0027re not affected.\n\nTo reproduce the issue:\n\n- Pick the id for a variant with available stock. From the rails console:\n\n```ruby\nSpree::Variant.in_stock.pluck(:id)\n```\n\nSay we pick variant id `2`.\n\n- Launch your application, for instance,\n  on `http://localhost:3000`:\n\n```bash\nbin/rails server\n```\n\n- Open your browser dev tools.\n\n- Click on whatever link in your store.\n\n- Copy the value of the `Cookie` request header sent for the previous request\nfrom your browser dev tools.\n\n- Execute the following, using your previously selected variant id and the\nvalue of the `Cookie` header (notice how it doesn\u0027t contain any authentication\ntoken):\n\n```bash\ncurl -X POST -d \"variant_id=2\u0026quantity=1\" -H \"Cookie:\nguest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8;\n_sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D;\n__profilin=p%3Dt\" http://localhost:3000/orders/populate\n```\n\n- Reload your browser and look at how your cart got updated.\n\n### Patches\n\nPlease, upgrade `solidus` to versions `3.1.5`, `3.0.5` or `2.11.14`.\n\nAfter upgrading, make sure you read the \"Upgrade notes\"  section below.\n\n### Upgrade notes\n\nThe patch adds CSRF token verification to the \"Add to cart\" action. Adding\nforgery protection to a form that missed it can have some side effects.\n\n#### `InvalidAuthenticityToken` errors\n\nIf you\u0027re using the `:exception` strategy, it\u0027s likely that after upgrading,\nyou\u0027ll see more `ActionController::InvalidAuthenticityToken` errors popping out\nin your logs. Due to browser-side cache, a form can be re-rendered and sent without\nany attached request cookie (for instance, when re-opening a mobile browser). That\nwill cause an authentication error, as the sent token won\u0027t match with the one in\nthe session (none in this case). That\u0027s a known problem in the Rails community (see\nhttps://github.com/rails/rails/issues/21948), and, at this point, there\u0027s no perfect\nsolution.\n\nAny attempt to mitigate the issue should be seen at the application level.\nFor an excellent survey of all the available options, take a look at\nhttps://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md.\nThe latter is a third-party link. As the information is relevant here, we\u0027re going\nto copy it below, but it should be clear that all the credit goes to @kemenaran:\n\n\u003e # Protecting against request forgery using CRSF tokens\n\u003e\n\u003e ## Context\n\u003e\n\u003e Rails has CSRF protection enabled by default, to protect against POST-based CSRF attacks.\n\u003e\n\u003e To protect from this, Rails stores two copies of a random token (the so-named CSRF token) on each request:\n\u003e - one copy embedded in each HTML page,\n\u003e - another copy in the user session.\n\u003e\n\u003e When performing a POST request, Rails checks that the two copies match \u2013 and\n\u003e otherwise denies the request. This protects against an attacker that would\n\u003e generate a form secretly pointing to our website: the attacker can\u0027t read\n\u003e the token in the session, and so can\u0027t post a form with a valid token.\n\u003e\n\u003e The problem is that, much more often, this has false positives.\n\u003e There are several cases for that, including:\n\u003e\n\u003e 1. The web browser (often mobile) loads a page containing a form, then is\n\u003e closed by the user. Later, when the browser is re-opened, it restores the\n\u003e page from the cache. But the session cookie has expired, and so is not\n\u003e restored \u2013 so the copy of the CSRF token stored in the session is missing.\n\u003e When the user submits the form, they get an \"InvalidAuthenticityToken\"\n\u003e exception.\n\u003e\n\u003e 2. The user attempts to fill a form, and gets an error message (usually in\n\u003e response to a POST request). They close the browser. When the browser is\n\u003e re-opened, it attempts to restore the page. On Chrome this is blocked by the\n\u003e browser, because the browser denies retrying a (probably non-idempotent)\n\u003e POST request. Safari however happily retries the POST request \u2013 but without\n\u003e sending any cookies (in an attempt to avoid having unexpected side-effects).\n\u003e So the copy of the CSRF token in the session is missing (because no cookie\n\u003e was sent), and the user get an \"InvalidAuthenticityToken\" exception.\n\u003e\n\u003e ## Options considered\n\u003e\n\u003e ### Extend the session cookie duration\n\u003e\n\u003e We can configure the session cookie to be valid for a longer time (like 2\n\u003e weeks).\n\u003e\n\u003e Pros:\n\u003e - It solves 1., because when the browser restores the page, the session\n\u003e cookie is still valid.\n\u003e\n\u003e Cons:\n\u003e - Users would be signed-in for a much longer time by default, which has\n\u003e unacceptable security implications.\n\u003e - It doesn\u0027t solve 2. (because Safari doesn\u0027t send any cookie when restoring\n\u003e a page from a POST request)\n\u003e\n\u003e ### Change the cache parameters\n\u003e\n\u003e We can send a HTTP cache header stating \u0027Cache-Control: no-store, no-cache\u0027.\n\u003e This instructs the browser to never keep any copy of the page, and to always\n\u003e make a request to the server to restore it.\n\u003e\n\u003e This solution was attempted during a year in production, and solved 1.\n\u003e \u2013 but also introduced another type of InvalidAuthenticityToken errors. In\n\u003e that scenario, the user attempts to fill a form, and gets an error message\n\u003e (usually in response to a POST request). They then navigate on another domain (like\n\u003e France Connect), then hit the \"Back\" button. Crossing back the domain boundary\n\u003e may cause the browser to either block the request or retry an invalid POST request.\n\u003e\n\u003e Pros:\n\u003e - It solves 1., because on relaunch the browser requests a fresh page again\n\u003e (instead of serving it from its cache), thus retrieving a fresh session and\n\u003e a fresh matching CSRF token.\n\u003e\n\u003e Cons:\n\u003e - It doesn\u0027t solve 2.\n\u003e - It causes another type of InvalidAuthenticityToken errors.\n\u003e\n\u003e ### Using a null-session strategy\n\u003e\n\u003e We can change the default protect_from_forgery strategy to :null_session.\n\u003e This makes the current request use an empty session for the request duration.\n\u003e\n\u003e Pros:\n\u003e - It kind of solves 1., by redirecting to a \"Please sign-in\" page\n\u003e when a stale form is submitted.\n\u003e\n\u003e Cons:\n\u003e - The user is asked to sign-in only after filling and submitting the form,\n\u003e losing their time and data\n\u003e - The user will not be redirected to their original page after signing-in\n\u003e - It has potential security implications: as the (potentically malicious)\n\u003e request runs anyway, variables cached by a controller before the Null\n\u003e session is created may allow the form submission to succeed anyway\n\u003e (https://www.veracode.com/blog/managing-appsec/when-rails-protectfromforgery-fails)\n\u003e\n\u003e ### Using a reset-session strategy\n\u003e\n\u003e We can change the default protect_from_forgery strategy to :reset_session.\n\u003e This clears the user session permanently, logging them out until they log in\n\u003e again.\n\u003e\n\u003e Pros:\n\u003e - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a\n\u003e stale form is submitted.\n\u003e\n\u003e Cons:\n\u003e - A forgery error in a browser tab will disconnect the user in all its open\n\u003e tabs\n\u003e - It has potential security implications: as the (potentically malicious)\n\u003e request runs anyway, variables cached by a controller before the Null session\n\u003e is created may allow the form submission to succeed anyway\n\u003e (https://www.veracode.com/blog/managing-appsec/when-rails-protectfromforgery-fails)\n\u003e - It allows an attacker to disconnect an user on demand, which is not only\n\u003e inconvenient, but also has security implication (the attacker could then log\n\u003e the user on it\u0027s own attacker account, pretending to be the user account)\n\u003e\n\u003e ### Redirect to login form\n\u003e\n\u003e When a forgery error occurs, we can instead redirect to the login form.\n\u003e\n\u003e Pros:\n\u003e - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a\n\u003e stale form is submitted (but the user data is lost).\n\u003e - It kind of solves 2., by redirecting to a \"Please sign-in\" page when a\n\u003e previously POSTed form is reloaded.\n\u003e\n\u003e Cons:\n\u003e - Not all forms require authentication \u2013 so for\n\u003e public forms there is no point redirecting to the login form.\n\u003e - The user will not be redirected to their original page after signing-in\n\u003e (because setting the redirect path is a state-changing action, and it is\n\u003e dangerous to let an unauthorized request changing the state \u2013 an attacker\n\u003e could control the path where an user is automatically redirected to.)\n\u003e - The implementation is finicky, and may introduce security errors.\n\u003e For instance, a naive implementation that catches the exception and\n\u003e redirect_to the sign-in page will prevent Devise from running a cleanup code\n\u003e \u2013 which means the user will still be logged, and the CSRF protection is\n\u003e bypassed. However a well-tested implementation that lets Devise code run\n\u003e should avoid these pittfalls.\n\u003e\n\u003e ### Using a long-lived cookie for CSRF tokens\n\u003e\n\u003e Instead of storing the CSRF token in the session cookie (which is deleted\n\u003e when the browser is closed), we can instead store it in a longer-lived\n\u003e cookie. For this we need to patch Rails.\n\u003e\n\u003e Pros:\n\u003e - It solves 1., because when the user submits a stale form, even if the\n\u003e session cookie because stale, the long-lived CSRF cookie is still valid.\n\u003e\n\u003e Cons:\n\u003e - It doesn\u0027t solve 2., because when Safari retries a POST request, it sends\n\u003e none of the cookies (not even long-lived ones).\n\u003e - Patching Rails may introduce security issues (now or in the future)\n\n#### Broken behavior due to session expiration + template cache\n\nAlthough pretty unlikely, you should make sure that your current setup for\ncache/session expiration is compatible. The upgrade can break the addition\nof products to the cart if both:\n\n- The \"Add to cart\" form is being cached (usually along with the variant\ninformation).\n\n- A user session is reset at every or every few requests.\n\nThe token validation depends on the issuing and consuming sessions\nbeing the same. If a product page is cached with the token in it, it can\nbecome stale on a subsequent rendering if the session changes.\n\nTo check that you\u0027re safe, after having upgraded locally, go through the\nfollowing steps:\n\n- Enable cache on dev mode:\n\n```bash\nbin/rails dev:cache\n```\n\n- Visit the page for a variant with stock.\n\n- Reload that page several times.\n\n- Click on the \"Add to cart\"  button.\n\n- Remember to rerun `bin/rails dev:cache` to turn off cache again.\n\nNo error or session reset should happen.\n\nOtherwise, you can try with:\n\n- Revisiting how your session gets expired.\n- Changing the caching strategy to exclude the token.\n\n#### Using weaker CSRF protection strategies\n\nIt\u0027s also important to understand that a complete fix will only be in place\nwhen using the `:exception` forgery protection strategy. The\n`solidus_frontend` engine can\u0027t do pretty much anything otherwise. Using\nweaker CSRF strategies should be an informed and limited decision made by the\napplication team. After the upgrade:\n\n- An app using `:null_session` should also be safe, but there will be side\neffects. That strategy runs with a null object session. As such, no order and\nno user is found on it. A new `cart` state order is created in the database,\nassociated with no user. Next time the user visits the site, they won\u0027t find\nany difference in its cart state.\n\n- An app using `:reset_session` is not entirely safe. That strategy resets the\nsession. That means that registered users will be logged out. Next time a user\nvisits, they\u0027ll see the cart with the items added during the CSRF attack,\nalthough it won\u0027t be associated with their account in the case of registered\nusers.\n\n#### Reversing the update\n\nIf you still want to deploy the upgraded version before changing your\napplication code (if the latter is needed), you can add the following\nworkaround to your `config/application.rb` (however, take into account that\nyou\u0027ll keep being vulnerable):\n\n```ruby\nconfig.after_initialize do\n  Spree::OrdersController.skip_before_action :verify_authenticity_token, only:\n    [:populate]\nend\n```\n\n### Workarounds\n\nIf an upgrade is not an option, you can work around the issue by adding the\nfollowing to `config/application.rb`:\n\n```ruby\nconfig.after_initialize do\n  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym,\n    only: [:populate]\nend\n```\n\nHowever, go through the same safety check detailed on \"Upgrade notes\" above.\n\n### References\n\n- [CSRF on the Rails guides](https://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf)\n- [How CSRF tokens are generated and validated on Rails](https://medium.com/rubyinside/a-deep-dive-into-csrf-protection-in-rails-19fa0a42c0ef)\n- [Solidus security](https://solidus.io/security/)\n",
      "id": "GSD-2021-43846",
      "modified": "2022-01-06T00:00:00.000Z",
      "published": "2022-01-06T00:00:00.000Z",
      "references": [
        {
          "type": "WEB",
          "url": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
        },
        {
          "type": "WEB",
          "url": "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81"
        },
        {
          "type": "WEB",
          "url": "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6"
        }
      ],
      "schema_version": "1.4.0",
      "severity": [
        {
          "score": 5.3,
          "type": "CVSS_V3"
        }
      ],
      "summary": "CSRF forgery protection bypass in solidus_frontend"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "security-advisories@github.com",
        "ID": "CVE-2021-43846",
        "STATE": "PUBLIC",
        "TITLE": "CSRF forgery protection bypass for Spree::OrdersController#populate"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "solidus",
                    "version": {
                      "version_data": [
                        {
                          "version_value": "\u003e= 3.1.0, \u003c 3.1.5"
                        },
                        {
                          "version_value": "\u003e= 3.0.0, \u003c 3.0.5"
                        },
                        {
                          "version_value": "\u003c 2.11.14"
                        }
                      ]
                    }
                  }
                ]
              },
              "vendor_name": "solidusio"
            }
          ]
        }
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "`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\u0027s 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": {
        "cvss": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 5.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
          "version": "3.1"
        }
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "lang": "eng",
                "value": "CWE-352: Cross-Site Request Forgery (CSRF)"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m",
            "refsource": "CONFIRM",
            "url": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
          },
          {
            "name": "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81",
            "refsource": "MISC",
            "url": "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81"
          },
          {
            "name": "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6",
            "refsource": "MISC",
            "url": "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6"
          }
        ]
      },
      "source": {
        "advisory": "GHSA-h3fg-h5v3-vf8m",
        "discovery": "UNKNOWN"
      }
    },
    "github.com/rubysec/ruby-advisory-db": {
      "cve": "2021-43846",
      "cvss_v3": 5.3,
      "date": "2022-01-06",
      "description": "### Impact\nCSRF vulnerability that allows a malicious site to add an item to the user\u0027s\ncart without their knowledge.\n\nAll `solidus_frontend` versions are affected. If you\u0027re using your own\nstorefront, please, follow along to make sure you\u0027re not affected.\n\nTo reproduce the issue:\n\n- Pick the id for a variant with available stock. From the rails console:\n\n```ruby\nSpree::Variant.in_stock.pluck(:id)\n```\n\nSay we pick variant id `2`.\n\n- Launch your application, for instance,\n  on `http://localhost:3000`:\n\n```bash\nbin/rails server\n```\n\n- Open your browser dev tools.\n\n- Click on whatever link in your store.\n\n- Copy the value of the `Cookie` request header sent for the previous request\nfrom your browser dev tools.\n\n- Execute the following, using your previously selected variant id and the\nvalue of the `Cookie` header (notice how it doesn\u0027t contain any authentication\ntoken):\n\n```bash\ncurl -X POST -d \"variant_id=2\u0026quantity=1\" -H \"Cookie:\nguest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8;\n_sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D;\n__profilin=p%3Dt\" http://localhost:3000/orders/populate\n```\n\n- Reload your browser and look at how your cart got updated.\n\n### Patches\n\nPlease, upgrade `solidus` to versions `3.1.5`, `3.0.5` or `2.11.14`.\n\nAfter upgrading, make sure you read the \"Upgrade notes\"  section below.\n\n### Upgrade notes\n\nThe patch adds CSRF token verification to the \"Add to cart\" action. Adding\nforgery protection to a form that missed it can have some side effects.\n\n#### `InvalidAuthenticityToken` errors\n\nIf you\u0027re using the `:exception` strategy, it\u0027s likely that after upgrading,\nyou\u0027ll see more `ActionController::InvalidAuthenticityToken` errors popping out\nin your logs. Due to browser-side cache, a form can be re-rendered and sent without\nany attached request cookie (for instance, when re-opening a mobile browser). That\nwill cause an authentication error, as the sent token won\u0027t match with the one in\nthe session (none in this case). That\u0027s a known problem in the Rails community (see\nhttps://github.com/rails/rails/issues/21948), and, at this point, there\u0027s no perfect\nsolution.\n\nAny attempt to mitigate the issue should be seen at the application level.\nFor an excellent survey of all the available options, take a look at\nhttps://github.com/betagouv/demarches-simplifiees.fr/blob/5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9/doc/adr-csrf-forgery.md.\nThe latter is a third-party link. As the information is relevant here, we\u0027re going\nto copy it below, but it should be clear that all the credit goes to @kemenaran:\n\n\u003e # Protecting against request forgery using CRSF tokens\n\u003e\n\u003e ## Context\n\u003e\n\u003e Rails has CSRF protection enabled by default, to protect against POST-based CSRF attacks.\n\u003e\n\u003e To protect from this, Rails stores two copies of a random token (the so-named CSRF token) on each request:\n\u003e - one copy embedded in each HTML page,\n\u003e - another copy in the user session.\n\u003e\n\u003e When performing a POST request, Rails checks that the two copies match \u2013 and\n\u003e otherwise denies the request. This protects against an attacker that would\n\u003e generate a form secretly pointing to our website: the attacker can\u0027t read\n\u003e the token in the session, and so can\u0027t post a form with a valid token.\n\u003e\n\u003e The problem is that, much more often, this has false positives.\n\u003e There are several cases for that, including:\n\u003e\n\u003e 1. The web browser (often mobile) loads a page containing a form, then is\n\u003e closed by the user. Later, when the browser is re-opened, it restores the\n\u003e page from the cache. But the session cookie has expired, and so is not\n\u003e restored \u2013 so the copy of the CSRF token stored in the session is missing.\n\u003e When the user submits the form, they get an \"InvalidAuthenticityToken\"\n\u003e exception.\n\u003e\n\u003e 2. The user attempts to fill a form, and gets an error message (usually in\n\u003e response to a POST request). They close the browser. When the browser is\n\u003e re-opened, it attempts to restore the page. On Chrome this is blocked by the\n\u003e browser, because the browser denies retrying a (probably non-idempotent)\n\u003e POST request. Safari however happily retries the POST request \u2013 but without\n\u003e sending any cookies (in an attempt to avoid having unexpected side-effects).\n\u003e So the copy of the CSRF token in the session is missing (because no cookie\n\u003e was sent), and the user get an \"InvalidAuthenticityToken\" exception.\n\u003e\n\u003e ## Options considered\n\u003e\n\u003e ### Extend the session cookie duration\n\u003e\n\u003e We can configure the session cookie to be valid for a longer time (like 2\n\u003e weeks).\n\u003e\n\u003e Pros:\n\u003e - It solves 1., because when the browser restores the page, the session\n\u003e cookie is still valid.\n\u003e\n\u003e Cons:\n\u003e - Users would be signed-in for a much longer time by default, which has\n\u003e unacceptable security implications.\n\u003e - It doesn\u0027t solve 2. (because Safari doesn\u0027t send any cookie when restoring\n\u003e a page from a POST request)\n\u003e\n\u003e ### Change the cache parameters\n\u003e\n\u003e We can send a HTTP cache header stating \u0027Cache-Control: no-store, no-cache\u0027.\n\u003e This instructs the browser to never keep any copy of the page, and to always\n\u003e make a request to the server to restore it.\n\u003e\n\u003e This solution was attempted during a year in production, and solved 1.\n\u003e \u2013 but also introduced another type of InvalidAuthenticityToken errors. In\n\u003e that scenario, the user attempts to fill a form, and gets an error message\n\u003e (usually in response to a POST request). They then navigate on another domain (like\n\u003e France Connect), then hit the \"Back\" button. Crossing back the domain boundary\n\u003e may cause the browser to either block the request or retry an invalid POST request.\n\u003e\n\u003e Pros:\n\u003e - It solves 1., because on relaunch the browser requests a fresh page again\n\u003e (instead of serving it from its cache), thus retrieving a fresh session and\n\u003e a fresh matching CSRF token.\n\u003e\n\u003e Cons:\n\u003e - It doesn\u0027t solve 2.\n\u003e - It causes another type of InvalidAuthenticityToken errors.\n\u003e\n\u003e ### Using a null-session strategy\n\u003e\n\u003e We can change the default protect_from_forgery strategy to :null_session.\n\u003e This makes the current request use an empty session for the request duration.\n\u003e\n\u003e Pros:\n\u003e - It kind of solves 1., by redirecting to a \"Please sign-in\" page\n\u003e when a stale form is submitted.\n\u003e\n\u003e Cons:\n\u003e - The user is asked to sign-in only after filling and submitting the form,\n\u003e losing their time and data\n\u003e - The user will not be redirected to their original page after signing-in\n\u003e - It has potential security implications: as the (potentically malicious)\n\u003e request runs anyway, variables cached by a controller before the Null\n\u003e session is created may allow the form submission to succeed anyway\n\u003e (https://www.veracode.com/blog/managing-appsec/when-rails-protectfromforgery-fails)\n\u003e\n\u003e ### Using a reset-session strategy\n\u003e\n\u003e We can change the default protect_from_forgery strategy to :reset_session.\n\u003e This clears the user session permanently, logging them out until they log in\n\u003e again.\n\u003e\n\u003e Pros:\n\u003e - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a\n\u003e stale form is submitted.\n\u003e\n\u003e Cons:\n\u003e - A forgery error in a browser tab will disconnect the user in all its open\n\u003e tabs\n\u003e - It has potential security implications: as the (potentically malicious)\n\u003e request runs anyway, variables cached by a controller before the Null session\n\u003e is created may allow the form submission to succeed anyway\n\u003e (https://www.veracode.com/blog/managing-appsec/when-rails-protectfromforgery-fails)\n\u003e - It allows an attacker to disconnect an user on demand, which is not only\n\u003e inconvenient, but also has security implication (the attacker could then log\n\u003e the user on it\u0027s own attacker account, pretending to be the user account)\n\u003e\n\u003e ### Redirect to login form\n\u003e\n\u003e When a forgery error occurs, we can instead redirect to the login form.\n\u003e\n\u003e Pros:\n\u003e - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a\n\u003e stale form is submitted (but the user data is lost).\n\u003e - It kind of solves 2., by redirecting to a \"Please sign-in\" page when a\n\u003e previously POSTed form is reloaded.\n\u003e\n\u003e Cons:\n\u003e - Not all forms require authentication \u2013 so for\n\u003e public forms there is no point redirecting to the login form.\n\u003e - The user will not be redirected to their original page after signing-in\n\u003e (because setting the redirect path is a state-changing action, and it is\n\u003e dangerous to let an unauthorized request changing the state \u2013 an attacker\n\u003e could control the path where an user is automatically redirected to.)\n\u003e - The implementation is finicky, and may introduce security errors.\n\u003e For instance, a naive implementation that catches the exception and\n\u003e redirect_to the sign-in page will prevent Devise from running a cleanup code\n\u003e \u2013 which means the user will still be logged, and the CSRF protection is\n\u003e bypassed. However a well-tested implementation that lets Devise code run\n\u003e should avoid these pittfalls.\n\u003e\n\u003e ### Using a long-lived cookie for CSRF tokens\n\u003e\n\u003e Instead of storing the CSRF token in the session cookie (which is deleted\n\u003e when the browser is closed), we can instead store it in a longer-lived\n\u003e cookie. For this we need to patch Rails.\n\u003e\n\u003e Pros:\n\u003e - It solves 1., because when the user submits a stale form, even if the\n\u003e session cookie because stale, the long-lived CSRF cookie is still valid.\n\u003e\n\u003e Cons:\n\u003e - It doesn\u0027t solve 2., because when Safari retries a POST request, it sends\n\u003e none of the cookies (not even long-lived ones).\n\u003e - Patching Rails may introduce security issues (now or in the future)\n\n#### Broken behavior due to session expiration + template cache\n\nAlthough pretty unlikely, you should make sure that your current setup for\ncache/session expiration is compatible. The upgrade can break the addition\nof products to the cart if both:\n\n- The \"Add to cart\" form is being cached (usually along with the variant\ninformation).\n\n- A user session is reset at every or every few requests.\n\nThe token validation depends on the issuing and consuming sessions\nbeing the same. If a product page is cached with the token in it, it can\nbecome stale on a subsequent rendering if the session changes.\n\nTo check that you\u0027re safe, after having upgraded locally, go through the\nfollowing steps:\n\n- Enable cache on dev mode:\n\n```bash\nbin/rails dev:cache\n```\n\n- Visit the page for a variant with stock.\n\n- Reload that page several times.\n\n- Click on the \"Add to cart\"  button.\n\n- Remember to rerun `bin/rails dev:cache` to turn off cache again.\n\nNo error or session reset should happen.\n\nOtherwise, you can try with:\n\n- Revisiting how your session gets expired.\n- Changing the caching strategy to exclude the token.\n\n#### Using weaker CSRF protection strategies\n\nIt\u0027s also important to understand that a complete fix will only be in place\nwhen using the `:exception` forgery protection strategy. The\n`solidus_frontend` engine can\u0027t do pretty much anything otherwise. Using\nweaker CSRF strategies should be an informed and limited decision made by the\napplication team. After the upgrade:\n\n- An app using `:null_session` should also be safe, but there will be side\neffects. That strategy runs with a null object session. As such, no order and\nno user is found on it. A new `cart` state order is created in the database,\nassociated with no user. Next time the user visits the site, they won\u0027t find\nany difference in its cart state.\n\n- An app using `:reset_session` is not entirely safe. That strategy resets the\nsession. That means that registered users will be logged out. Next time a user\nvisits, they\u0027ll see the cart with the items added during the CSRF attack,\nalthough it won\u0027t be associated with their account in the case of registered\nusers.\n\n#### Reversing the update\n\nIf you still want to deploy the upgraded version before changing your\napplication code (if the latter is needed), you can add the following\nworkaround to your `config/application.rb` (however, take into account that\nyou\u0027ll keep being vulnerable):\n\n```ruby\nconfig.after_initialize do\n  Spree::OrdersController.skip_before_action :verify_authenticity_token, only:\n    [:populate]\nend\n```\n\n### Workarounds\n\nIf an upgrade is not an option, you can work around the issue by adding the\nfollowing to `config/application.rb`:\n\n```ruby\nconfig.after_initialize do\n  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym,\n    only: [:populate]\nend\n```\n\nHowever, go through the same safety check detailed on \"Upgrade notes\" above.\n\n### References\n\n- [CSRF on the Rails guides](https://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf)\n- [How CSRF tokens are generated and validated on Rails](https://medium.com/rubyinside/a-deep-dive-into-csrf-protection-in-rails-19fa0a42c0ef)\n- [Solidus security](https://solidus.io/security/)\n",
      "gem": "solidus_frontend",
      "ghsa": "h3fg-h5v3-vf8m",
      "patched_versions": [
        "\u003e= 3.1.5",
        "~\u003e 3.0.5",
        "~\u003e 2.11.14"
      ],
      "related": {
        "url": [
          "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81",
          "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6"
        ]
      },
      "title": "CSRF forgery protection bypass in solidus_frontend",
      "url": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
    },
    "gitlab.com": {
      "advisories": [
        {
          "affected_range": "\u003c2.11.14||\u003e=3.0.0 \u003c3.0.5||\u003e=3.1.0 \u003c3.1.5",
          "affected_versions": "All versions before 2.11.14, all versions starting from 3.0.0 before 3.0.5, all versions starting from 3.1.0 before 3.1.5",
          "cvss_v2": "AV:N/AC:M/Au:N/C:N/I:P/A:N",
          "cvss_v3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
          "cwe_ids": [
            "CWE-1035",
            "CWE-352",
            "CWE-937"
          ],
          "date": "2021-12-29",
          "description": "`solidus_frontend` is the cart and storefront for the Solidus e-commerce project. Versions of `solidus_frontend` contain a cross-site request forgery (CSRF) vulnerability that allows a malicious site to add an item to the user\u0027s cart without their knowledge. 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.",
          "fixed_versions": [
            "2.11.14",
            "3.0.5",
            "3.1.5"
          ],
          "identifier": "CVE-2021-43846",
          "identifiers": [
            "CVE-2021-43846",
            "GHSA-h3fg-h5v3-vf8m"
          ],
          "not_impacted": "All versions starting from 2.11.14 before 3.0.0, all versions starting from 3.0.5 before 3.1.0, all versions starting from 3.1.5",
          "package_slug": "gem/solidus_api",
          "pubdate": "2021-12-20",
          "solution": "Upgrade to versions 2.11.14, 3.0.5, 3.1.5 or above.",
          "title": "Cross-Site Request Forgery (CSRF)",
          "urls": [
            "https://nvd.nist.gov/vuln/detail/CVE-2021-43846",
            "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81",
            "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6",
            "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
          ],
          "uuid": "6ffab43a-cce4-4365-96b6-eb60f9222430"
        },
        {
          "affected_range": "\u003c2.11.14||\u003e=3.0.0 \u003c3.0.5||\u003e=3.1.0 \u003c3.1.5",
          "affected_versions": "All versions before 2.11.14, all versions starting from 3.0.0 before 3.0.5, all versions starting from 3.1.0 before 3.1.5",
          "cvss_v2": "AV:N/AC:M/Au:N/C:N/I:P/A:N",
          "cvss_v3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
          "cwe_ids": [
            "CWE-1035",
            "CWE-352",
            "CWE-937"
          ],
          "date": "2021-12-29",
          "description": "`solidus_frontend` is the cart and storefront for the Solidus e-commerce project. Versions of `solidus_frontend` contain a cross-site request forgery (CSRF) vulnerability that allows a malicious site to add an item to the user\u0027s cart without their knowledge. 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.",
          "fixed_versions": [
            "2.11.14",
            "3.0.5",
            "3.1.5"
          ],
          "identifier": "CVE-2021-43846",
          "identifiers": [
            "CVE-2021-43846",
            "GHSA-h3fg-h5v3-vf8m"
          ],
          "not_impacted": "All versions starting from 2.11.14 before 3.0.0, all versions starting from 3.0.5 before 3.1.0, all versions starting from 3.1.5",
          "package_slug": "gem/solidus_core",
          "pubdate": "2021-12-20",
          "solution": "Upgrade to versions 2.11.14, 3.0.5, 3.1.5 or above.",
          "title": "Cross-Site Request Forgery (CSRF)",
          "urls": [
            "https://nvd.nist.gov/vuln/detail/CVE-2021-43846",
            "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81",
            "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6",
            "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
          ],
          "uuid": "26343718-5888-4ce4-b111-7f0161f4cca1"
        },
        {
          "affected_range": "\u003c2.11.14||\u003e=3.0.0 \u003c3.0.5||\u003e=3.1.0 \u003c3.1.5",
          "affected_versions": "All versions before 2.11.14, all versions starting from 3.0.0 before 3.0.5, all versions starting from 3.1.0 before 3.1.5",
          "cvss_v2": "AV:N/AC:M/Au:N/C:N/I:P/A:N",
          "cvss_v3": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
          "cwe_ids": [
            "CWE-1035",
            "CWE-352",
            "CWE-937"
          ],
          "date": "2021-12-29",
          "description": "`solidus_frontend` is the cart and storefront for the Solidus e-commerce project. Versions of `solidus_frontend` contain a cross-site request forgery (CSRF) vulnerability that allows a malicious site to add an item to the user\u0027s cart without their knowledge. 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.",
          "fixed_versions": [
            "2.11.14",
            "3.0.5",
            "3.1.5"
          ],
          "identifier": "CVE-2021-43846",
          "identifiers": [
            "CVE-2021-43846",
            "GHSA-h3fg-h5v3-vf8m"
          ],
          "not_impacted": "All versions starting from 2.11.14 before 3.0.0, all versions starting from 3.0.5 before 3.1.0, all versions starting from 3.1.5",
          "package_slug": "gem/solidus_frontend",
          "pubdate": "2021-12-20",
          "solution": "Upgrade to versions 2.11.14, 3.0.5, 3.1.5 or above.",
          "title": "Cross-Site Request Forgery (CSRF)",
          "urls": [
            "https://nvd.nist.gov/vuln/detail/CVE-2021-43846",
            "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81",
            "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6",
            "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
          ],
          "uuid": "307ae914-ff26-4a03-8d62-b1708dfe6804"
        }
      ]
    },
    "nvd.nist.gov": {
      "configurations": {
        "CVE_data_version": "4.0",
        "nodes": [
          {
            "children": [],
            "cpe_match": [
              {
                "cpe23Uri": "cpe:2.3:a:nebulab:solidus:*:*:*:*:*:*:*:*",
                "cpe_name": [],
                "versionEndExcluding": "2.11.14",
                "vulnerable": true
              },
              {
                "cpe23Uri": "cpe:2.3:a:nebulab:solidus:*:*:*:*:*:*:*:*",
                "cpe_name": [],
                "versionEndExcluding": "3.0.5",
                "versionStartIncluding": "3.0.0",
                "vulnerable": true
              },
              {
                "cpe23Uri": "cpe:2.3:a:nebulab:solidus:*:*:*:*:*:*:*:*",
                "cpe_name": [],
                "versionEndExcluding": "3.1.5",
                "versionStartIncluding": "3.1.0",
                "vulnerable": true
              }
            ],
            "operator": "OR"
          }
        ]
      },
      "cve": {
        "CVE_data_meta": {
          "ASSIGNER": "security-advisories@github.com",
          "ID": "CVE-2021-43846"
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "en",
              "value": "`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\u0027s 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."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "en",
                  "value": "CWE-352"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81",
              "refsource": "MISC",
              "tags": [
                "Patch",
                "Third Party Advisory"
              ],
              "url": "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81"
            },
            {
              "name": "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6",
              "refsource": "MISC",
              "tags": [
                "Patch",
                "Third Party Advisory"
              ],
              "url": "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6"
            },
            {
              "name": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m",
              "refsource": "CONFIRM",
              "tags": [
                "Exploit",
                "Mitigation",
                "Third Party Advisory"
              ],
              "url": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
            }
          ]
        }
      },
      "impact": {
        "baseMetricV2": {
          "acInsufInfo": false,
          "cvssV2": {
            "accessComplexity": "MEDIUM",
            "accessVector": "NETWORK",
            "authentication": "NONE",
            "availabilityImpact": "NONE",
            "baseScore": 4.3,
            "confidentialityImpact": "NONE",
            "integrityImpact": "PARTIAL",
            "vectorString": "AV:N/AC:M/Au:N/C:N/I:P/A:N",
            "version": "2.0"
          },
          "exploitabilityScore": 8.6,
          "impactScore": 2.9,
          "obtainAllPrivilege": false,
          "obtainOtherPrivilege": false,
          "obtainUserPrivilege": false,
          "severity": "MEDIUM",
          "userInteractionRequired": true
        },
        "baseMetricV3": {
          "cvssV3": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
            "version": "3.1"
          },
          "exploitabilityScore": 2.8,
          "impactScore": 1.4
        }
      },
      "lastModifiedDate": "2021-12-29T18:26Z",
      "publishedDate": "2021-12-20T22:15Z"
    }
  }
}

FKIE_CVE-2021-43846

Vulnerability from fkie_nvd - Published: 2021-12-20 22:15 - Updated: 2024-11-21 06:29

Severity ?

5.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
4.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

Summary

References

URL	Tags
security-advisories@github.com	https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81	Patch, Third Party Advisory
security-advisories@github.com	https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6	Patch, Third Party Advisory
security-advisories@github.com	https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m	Exploit, Mitigation, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108	https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81	Patch, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108	https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6	Patch, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108	https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m	Exploit, Mitigation, Third Party Advisory

Impacted products

Vendor	Product	Version
nebulab	solidus	*
nebulab	solidus	*
nebulab	solidus	*

JSON

To clipboard

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:nebulab:solidus:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "BBFCB5C4-83E5-4AD7-8C52-92B863DD15B6",
              "versionEndExcluding": "2.11.14",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:nebulab:solidus:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "B58D450A-ADBF-4E0F-9C11-B11752ADE39E",
              "versionEndExcluding": "3.0.5",
              "versionStartIncluding": "3.0.0",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:nebulab:solidus:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "3A7D9C43-3C12-4B42-8DB2-FF18AD5BEF0E",
              "versionEndExcluding": "3.1.5",
              "versionStartIncluding": "3.1.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "`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\u0027s 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."
    },
    {
      "lang": "es",
      "value": "\"solidus_frontend\" es el carrito y el escaparate del proyecto de comercio electr\u00f3nico Solidus. Las versiones de \"solidus_frontend\" anteriores a 3.1.5, 3.0.5 y 2.11.14, contienen una vulnerabilidad de tipo cross-site request forgery (CSRF) que permite a un sitio malicioso a\u00f1adir un art\u00edculo al carrito del usuario sin su conocimiento. Las versiones 3.1.5, 3.0.5 y 2.11.14 contienen un parche para este problema. El parche a\u00f1ade la verificaci\u00f3n del token CSRF a la acci\u00f3n \"Add to cart\". A\u00f1adir protecci\u00f3n contra falsificaciones a un formulario que no la ten\u00eda puede tener algunos efectos secundarios. Est\u00e1n disponibles otras estrategias de protecci\u00f3n contra CSRF, as\u00ed como una soluci\u00f3n que implica la modificaci\u00f3n del archivo config/application.rb. M\u00e1s detalles sobre estas mitigaciones est\u00e1n disponibles en el aviso de seguridad de GitHub"
    }
  ],
  "id": "CVE-2021-43846",
  "lastModified": "2024-11-21T06:29:55.173",
  "metrics": {
    "cvssMetricV2": [
      {
        "acInsufInfo": false,
        "baseSeverity": "MEDIUM",
        "cvssData": {
          "accessComplexity": "MEDIUM",
          "accessVector": "NETWORK",
          "authentication": "NONE",
          "availabilityImpact": "NONE",
          "baseScore": 4.3,
          "confidentialityImpact": "NONE",
          "integrityImpact": "PARTIAL",
          "vectorString": "AV:N/AC:M/Au:N/C:N/I:P/A:N",
          "version": "2.0"
        },
        "exploitabilityScore": 8.6,
        "impactScore": 2.9,
        "obtainAllPrivilege": false,
        "obtainOtherPrivilege": false,
        "obtainUserPrivilege": false,
        "source": "nvd@nist.gov",
        "type": "Primary",
        "userInteractionRequired": true
      }
    ],
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 5.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 1.4,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 4.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 1.4,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2021-12-20T22:15:07.947",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch",
        "Third Party Advisory"
      ],
      "url": "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch",
        "Third Party Advisory"
      ],
      "url": "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Mitigation",
        "Third Party Advisory"
      ],
      "url": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch",
        "Third Party Advisory"
      ],
      "url": "https://github.com/solidusio/solidus/commit/4d17cacf066d9492fc04eb3a0b16084b47376d81"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Patch",
        "Third Party Advisory"
      ],
      "url": "https://github.com/solidusio/solidus/commit/a1b9bf7f24f9b8684fc4d943eacb02b1926c77c6"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Exploit",
        "Mitigation",
        "Third Party Advisory"
      ],
      "url": "https://github.com/solidusio/solidus/security/advisories/GHSA-h3fg-h5v3-vf8m"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-352"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

CVE-2021-43846 (GCVE-0-2021-43846)

GHSA-H3FG-H5V3-VF8M

Impact

Patches

Upgrade notes

InvalidAuthenticityToken errors

Protecting against request forgery using CRSF tokens

Context

Options considered

Extend the session cookie duration

Change the cache parameters

Using a null-session strategy

Using a reset-session strategy

Redirect to login form

Using a long-lived cookie for CSRF tokens

Broken behavior due to session expiration + template cache

Using weaker CSRF protection strategies

Reversing the update

Workarounds

References

For more information

GSD-2021-43846

FKIE_CVE-2021-43846

Tags

Sightings

Nomenclature

`InvalidAuthenticityToken` errors