Supply Chain Security in B2C Commerce

Code Uploads

Uploading code is a sensitive operation. Any possibility of uploading untrusted code opens the doors for malicious actors to access most of your realm’s data and capabilities, which adversely affects the confidentiality, integrity, and availability of your site and customers’ data.

Third-Party Libraries

Third-party software is regularly integrated into custom code to easily add features and increase the speed to take a product to market. This practice comes at the risk of including unwanted or insecure libraries into the storefront code. Even SiteGenesis and Salesforce Reference Architecture (SFRA) include a number of third-party libraries. When incorporated into your custom code, they require close monitoring for potential issues and vulnerabilities.

To help prevent including potentially unwanted or vulnerable libraries in your storefront, follow these guidelines.

• Keep an inventory of required libraries for the correct operation of your storefront.
• Discard unnecessary libraries from your code base.
• Obtain third-party software from trusted, secure sources.
• Track the specific version of each library you use.
• Review the libraries for known weaknesses regularly, and upgrade to secure and supported versions of those libraries.

Remotely Hosted Resources

Supply chain attacks are more common in the ecommerce space today. For example, Magecart often targets third-party, remotely hosted resources to install drivebys that skim sensitive information entered on a webpage. Using only JavaScript, attackers can mine cryptocurrencies, assert machines into a DDoS network as subordinates, and even attempt to install malware directly onto the client machine for further control and compromise.

To do this, attackers compromise a remotely hosted resource and insert malicious code into a once-trusted JavaScript resource. Then, any websites that include the script also include the malicious JavaScript.

Recently, the security industry introduced new controls that help curb this type of attack. These controls insert integrity hashes into HTML elements that include remote resources. For example, Subresource Integrity (SI), a security feature that enables browsers to verify resources that they fetch, expects an integrity value on the HTML element that has a hash of the remote resource's content. If an attacker compromises the remote resource, the hash value won’t match the preconfigured and trusted hash value, and the client’s browser doesn’t load the malicious script.

For SFRA implementations, the addJs and addCss helper methods accept an integrity hash as an optional secondary argument. See the Mozilla Developer Network documentation for examples on implementing subresource integrity.