org.sonar.l10n.javascript.rules.javascript.S5725.html Maven / Gradle / Ivy
Using remote artifacts without integrity checks can lead to the unexpected execution of malicious code in the application.
On the client side, where front-end code is executed, malicious code could:
- impersonate users' identities and take advantage of their privileges on the application.
- add quiet malware that monitors users' session and capture sensitive secrets.
- gain access to sensitive clients' personal data.
- deface, or otherwise affect the general availability of the application.
- mine cryptocurrencies in the background.
Likewise, a compromised software piece that would be deployed on a server-side application could badly affect the application’s security. For
example, server-side malware could:
- access and modify sensitive technical and business data.
- elevate its privileges on the underlying operating system.
- Use the compromised application as a pivot to attack the local network.
By ensuring that a remote artifact is exactly what it is supposed to be before using it, the application is protected from unexpected changes
applied to it before it is downloaded.
Especially, integrity checks will allow for identifying an artifact replaced by malware on the publication
website or that was legitimately changed by its author, in a more benign scenario.
Important note: downloading an artifact over HTTPS only protects it while in transit from one host to another. It provides authenticity and
integrity checks for the network stream only. It does not ensure the authenticity or security of the artifact itself.
Ask Yourself Whether
- The artifact is a file intended to execute code.
- The artifact is a file that is intended to configure or affect running code in some way.
There is a risk if you answered yes to any of these questions.
Recommended Secure Coding Practices
To check the integrity of a remote artifact, hash verification is the most reliable solution. It does ensure that the file has not been modified
since the fingerprint was computed.
In this case, the artifact’s hash must:
- Be computed with a secure hash algorithm such as
SHA512, SHA384 or SHA256.
- Be compared with a secure hash that was not downloaded from the same source.
To do so, the best option is to add the hash in the code explicitly, by following Mozilla’s official documentation on
how to generate integrity strings.
Note: Use this fix together with version binding on the remote file. Avoid downloading files named "latest" or similar, so that the
front-end pages do not break when the code of the latest remote artifact changes.
Sensitive Code Example
The following code sample uses neither integrity checks nor version pinning:
let script = document.createElement("script");
script.src = "https://cdn.example.com/latest/script.js"; // Sensitive
script.crossOrigin = "anonymous";
document.head.appendChild(script);
Compliant Solution
let script = document.createElement("script");
script.src = "https://cdn.example.com/v5.3.6/script.js";
script.integrity = "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC";
script.crossOrigin = "anonymous";
document.head.appendChild(script);
See
- OWASP Top 10 2021 Category A8 - Software and Data
Integrity Failures
- MITRE, CWE-353 - Missing Support for Integrity Check
- OWASP Top 10 2017 Category
A6 - Security Misconfiguration
- developer.mozilla.org - Subresource Integrity
- Wikipedia, Watering Hole Attacks