A few days back, I was out for coffee with one of my friends. And as we conversed about everything under the sun, I got to know that he had lost a few bucks while performing an online transaction.

I was intrigued and asked him when did he realize he had lost the money. He said after he filled in a few details on the website.

Second, I found out if he had done any unusual activity on the site. To this, he said that he had clicked on a link.

I kept a note of all those points and the next day at work; I spoke to Radhika, one of my colleagues who is also a Salesforce Commerce expert. I gave her the background, and she immediately said that it was a classic case of cross-site request forgery (CSRF). It spiked my interest further because I had already made up my mind to write my next blog on Cross-Site request Forgery.

Radhika agreed and here goes a few excerpts from the detailed conversation that I had with her.

Radhika: Did you know in 2021, losses to online payment fraud were estimated up to $20 billion? Also, the eCommerce fraud detection and prevention market are expected to grow over two folds between 2021 and 2025, nearing $70 billion. (Statista)

Shraddha: What is Cross-Site Request Forgery?

Radhika: Cross-Site Request Forgery (CSRF) occurs when a malicious website, instant message, blog, email, or a program makes the user’s web browser perform an unwanted action on a trusted site where the user is authenticated. A CSRF attack is likely because a browser request automatically includes all cookies along with session cookies. Therefore, when the user is authenticated to the site, the site cannot distinguish between legitimate authorized requests and forged requests. Also, the attack happens when proper authorization is used.

The impact of a successful CSRF is huge. It’s devastating both for the business and the user. It can damage a client relationship, cause unauthorized fund transfers, change passwords, and data theft.

For my readers below is the diagram that Radhika had used for giving me a better clarity:

Shraddha: Do you think SFCC can prevent instances of CSRF?

Radhika: Every storefront has some protected requests that need a high level of security. Authenticated shoppers who change their accounts or submit personal data to a server to complete an action typically perform these requests.

Cross-site request forgery (CSRF) tricks the user’s browser into making this protected request without their knowledge, but with their authorization through a malicious link. The link forces the victim’s browser to make a request to another site and execute an unwanted action. For this, the victim should be authenticated on the other site. Some such examples include:

  • Customer logs into banking application to check a balance
  • Customer receives an email with a link to win some prize
  • Customer clicks a link
  • Customer’s browser actually makes a request to the banking application to perform a transfer of funds from the victim’s bank account to the attacker’s bank account
  • Customer might or might not immediately know that this action took place

Also, an attacker can force a victim to buy unwanted items, ship baskets to another address, or change user passwords.

The good news is Salesforce B2C Commerce has a CSRF protection software library so that developers can protect requests against this attack.

The CSRF protection API uses a Synchronizer Token pattern that requires random challenge tokens associated with the user’s current session. When the user submits content from the page, the server is configured to look for and validate that token. If the token validation fails, the request is rejected.

For sensitive businesses, including a required security token in HTTP; requests can mitigate CSRF attacks. It’s because the attacker needs to know the randomly generated token for a particular session.

Shraddha: What do you mean by Token-Based Mitigation?

Radhika: The synchronizer token pattern is one of the most popular and recommended methods to mitigate CSRF.

Synchronizer Token Pattern

CSRF tokens should be generated on the server-side. Per-user session or for each request, these tokens can be generated once.

Pro Tip: Per-request tokens are more secure than per-session tokens because the time an attacker gets (in the per-session tokens) to exploit the token is minimal.

But there is a problem as well. It may raise usability concerns. For instance, the “Back” button browser capability is often disabled since the previous page contains a token that is no longer valid. Interaction with the previous page can cause a CSRF false positive security event on the server. In the per-session token implementation after the initial generation of the token, the value is stored in the session and is used for each subsequent request until the session expires.

When the client issues a request, the server-side component should verify the validity of the token in the request compared to the token found in the user session. If the token isn’t found within the request, or the value provided does not match the value within the user session, then the request should be aborted. Additional actions, such as logging the event as a potential CSRF attack in progress should also be considered.

To Ponder: CSRF tokens prevent CSRF because, without a token, an attacker cannot create a valid request to the backend server

Pro Tip: CSRF tokens should not be transmitted using cookies

Shraddha: Hey Radhika, do you think that there are some specific ways that SFCC developers should keep in mind while developing a platform so that instances of CSRF can be blocked.

Radhika: Yes, of course there are ways to do so. In fact, from a developer’s perspective there are eleven best practices.

Shraddha: Oh! That’s fantastic

The Top 11 Security Best Practices for SFCC Developers to prevent CSRF

It is imperative that a B2C Commerce Developer uses some security best practices to develop secure storefronts. Some of them are:

  1. Encryption and Cryptography
    Salesforce B2C Commerce extends Salesforce-maintained cryptography libraries that help you encrypt, sign, and generate cryptographically strong tokens and secure random identifiers.

  2. Cross-Site Scripting
    Cross-site scripting (XSS) lets attackers inject client-side JavaScripts into a webpage viewed by a targeted user. For preventing malicious attacks through content manipulation, you must encode all user-provided content.

  3. Declarative Security via HTTP Headers
    You can use declarative security controls against client browser-based attacks, such as clickjacking, and offer built-in browser protection against cross-site scripting (XSS).

  4. Commerce Script Injection
    Server script injection, or remote code execution, happens when maliciously crafted input runs in a privileged code execution context. This class of attack lets an attacker control the code executed on the server.

  5. Cross-Site Request Forgery
    Every storefront contains some protected requests that require a high level of security protection. Authenticated shoppers who change their accounts or submit personal data to a server to complete an action typically perform these requests. Users expect that they alone make these requests, and only when they specifically initiate the request.

  6. Secret Storage
    Storing and using secrets is one of the most sensitive actions taken by a developer to ensure the security of shopper information.

  7. Using Hooks Securely
    In Salesforce B2C Commerce, you can use hooks as a powerful tool to extend default functionality. Like all powerful tools, even hooks are dangerous if not used properly.

  8. Data Validation
    Validating user input is the basis of application security. Data validation ensures that it is exactly the data that an application expects. Invalid requests are rejected outright, and an error is returned to users.

  9. Open Redirect Attacks
    When a web application trusts user input as a redirect destination, an attacker can use that input to redirect users to a website that they control and steal their information.

  10. Authentication and Authorization
    The exploitation of access control vulnerabilities is a core skill of attackers. To prevent such instances, you can enforce server-side access control checks for business functions such as account management, order management, and purchasing.

  11. Secure Logging
    Salesforce B2C Commerce logs are stored securely and are accessible only to users in the site_admin or developer roles.

The Final Note

Security being a primary concern it is imperative that retailers focus on having a platform that keeps away incidents of cyber-attacks like CSRF. A secure site is crucial to sustain the tough competition and build the trust of customers. Salesforce Commerce Cloud can offer your site optimum security so that both merchants and customers are in a win-win situation. Customers don’t lose their money and businesses do not lose the trust of their customers.

References:

  1. https://documentation.b2c.commercecloud.salesforce.com/DOC1/index.jsp?topic=%2Fcom.demandware.dochelp%2Fcontent%2Fb2c_commerce%2Ftopics%2Fb2c_security_best_practices%2Fb2c_cross_site_request_forgery.html
  2. https://documentation.b2c.commercecloud.salesforce.com/DOC1/index.jsp?topic=%2Fcom.demandware.dochelp%2FLegacyDevDoc%2FCrossSiteRequestForgeryProtection.html
  3. https://documentation.b2c.commercecloud.salesforce.com/DOC1/index.jsp?topic=%2Fcom.demandware.dochelp%2Fcontent%2Fb2c_commerce%2Ftopics%2Fb2c_security_best_practices%2Fb2c_security_best_practices_for_developers.html