Cross-Site Request Forgery Protection Framework

Introduction

Every storefront contains a number of protected requests. Authenticated users who are changing something about their accounts, or submitting personal data to a server to complete an action typically do these requests.

Users have an expectation that only they will ever be making those requests and only when they specifically initiate the request.

Cross-Site Request Forgery breaks that expectation by tricking a user’s browser into making this protected request without their knowledge, but with their authorization. The Commerce Cloud exposes a Cross-Site Request Forgery (CSRF) Protection Framework so that storefront developers may protect any kind of request against this attack.

Threats

  • Directly counteracts Cross-Site Request Forgery Attack
  • Can be defeated using Cross Site Scripting Attack

Why is this Best Practice Important?

Protecting Requests from Cross-Site Request Forgery is a best practice as it protects Storefront users from being tricked into purchasing extra items, or sending items to a different address. It protects against a loss of consumer confidence in the site.

How does this Best Practice protect against Threats?

  • The CSRF Protection Framework utilizes a custom built CSRF defense capability based on industry standards and best practices, called a synchronizer token. The token is generated on Commerce Cloud’s servers in such a way that only that Commerce Cloud server can validate it. The token is then inserted into HTML content served to storefront users. When a user submits a request with the token and the server is configured to expect and validate it, the server searches the request for the token and attempts to validate it. If it is valid, the request is allowed to proceed, otherwise the request is failed and the user who sent the request should be directed to a message explaining the request could not be validated.
  • The Commerce Cloud recommends generating a token for each protected request on a page. Each token will be unique and not impact performance in any noticeable way.
  • CSRF tokens are only valid for 60 minutes. If a request comes in after 60  minutes, it is invalid.
  • Whenever possible, CSRF tokens should be sent in the body of POST requests. This protects the request from being logged in a proxy, or by an application server in such a way that could be recoverable by attackers and re-used.
  • Furthermore, CSRF tokens gain an extra level of protection by being used over HTTPS. This decreases the likelihood that an attacker could successfully watch traffic from a client and intercept a token.
  • Finally, it is very important to only send CSRF tokens to your own domain. If requests send your CSRF tokens to a different website, the tokens are then dependent on the security of the other site and all connections to and from it and should not be trusted.

CAUTION: The CSRF Protection Framework utilizes information in a user's session. This means that the framework can only successfully validate tokens generated from the same session. The Framework should not be set on login forms as the session changes during that request. It is also illogical to protect the login form as an attacker would be unable to CSRF that form without knowledge of the victim user's username and password.

Does this Best Practice not protect against any part of a Threat?

This CSRF protection can always be defeated by XSS. This is because an XSS attack could simply steal the token and use it in a CSRF attack. If there is no XSS on a site, the CSRF defense is complete.

Code Examples

Example of Bad Practice

The following example is a standard form, sending edited shipping data to the storefront. An attacker is easily able to attack this via CSRF.

				
					<form action="$URLUtils.http('UserAccount-EditShippingAddress')}" method="POST">
    <input type="text" name="user_shipping_street">
    <input type="text" name="user_shipping_zip">
    <input type="Submit" value="Edit Address">
</form>
				
			

Example of Best Practice

The following example is a standard form, sending edited shipping data to the storefront but sending as well a generated CSRF Token that only Salesforce Commerce Cloud’s servers can validate.

				
					<form action="$URLUtils.http('UserAccount-EditShippingAddress')}" method="POST">
    <input type="text" name="user_shipping_street">
    <input type="text" name="user_shipping_zip">
    <input type="hidden" name="${dw.util.CSRFProtection.getCSRFTokenName()}" value="${dw.util.CSRFProtection.generateCSRFToken()}">
    <input type="Submit" value="Edit Address">
</form>
				
			

How to be a Certified Salesforce Commerce Cloud Developer for FREE

Unlock a FREE PDF with SFCC B2C Certification questions from our Udemy Course. Join our newsletter!
Check your email, you’ll receive a copy in a few seconds. If you don’t see it, please check your spam folder.

Do you like cookies? 🍪 We use cookies to ensure you get the best experience on our website. Learn more.