You are here:
Supply Chain Security in B2C Commerce
Unverified software sources included through uploads and external linking represent potential vectors for attack.
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 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.
Attackers do this by compromising a remotely hosted resource and inserting 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 by inserting integrity hashes into HTML elements that include remote resources. For example, Subresource Integrity (SI), a security feature that lets browsers verify resources that they fetch, expects an integrity value on the HTML element that has a hash of the remote resource's content. If the remote resource is compromised, 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.
