1. Introduction
Missing Subresource Integrity (SRI) means that resources fetched from third-party servers, like CDNs, aren’t checked for tampering. This allows an attacker to potentially inject malicious code into your website if the CDN is compromised. Websites using external scripts or stylesheets are usually affected. A successful attack could compromise confidentiality, integrity and availability of the web application.
2. Technical Explanation
SRI protects against attacks where a third-party server hosting resources used by your site is compromised. An attacker could replace legitimate files with malicious ones. Without SRI, browsers download these altered files without warning. The browser checks the hash of the downloaded file against a value you provide in the HTML. If they don’t match, the browser refuses to execute the resource.
- Root cause: Lack of integrity attributes on script or link tags referencing external resources.
- Exploit mechanism: An attacker compromises a CDN and replaces a JavaScript file with malicious code. Browsers download the altered file without SRI checking, leading to execution of the injected code.
- Scope: Any website using third-party hosted scripts or stylesheets is affected if SRI isn’t implemented.
3. Detection and Assessment
You can check for missing SRI by inspecting your site’s source code. A thorough assessment involves automated scanning tools.
- Quick checks: View the source code of a webpage and look for script or link tags without an `integrity` attribute.
- Scanning: Use web vulnerability scanners like OWASP ZAP or Burp Suite to identify missing SRI attributes. These are examples only, results may vary.
- Logs and evidence: Web server logs won’t directly show this issue. Browser developer tools can highlight failed SRI checks if they occur (look for errors related to resource loading).
grep -r 'src="[^"]*" integrity=' /path/to/your/website/files4. Solution / Remediation Steps
Add an `integrity` attribute to each script or link tag referencing external resources. This requires calculating a hash for the resource and encoding it correctly.
4.1 Preparation
- Ensure you have access to the original, unmodified versions of all external resources. A roll back plan is to revert the HTML file changes.
- Change windows should be planned and approved by the security team.
4.2 Implementation
- Step 1: Identify each script or link tag referencing an external resource without an `integrity` attribute.
- Step 2: Download the original resource file from its source (e.g., CDN).
- Step 3: Calculate the SHA-256 hash of the downloaded file using a tool like OpenSSL.
- Step 4: Add the `integrity` attribute to the tag, prefixed with `sha256-`, followed by the base64 encoded hash value.
- Step 5: Repeat steps 2-4 for each affected resource.
4.3 Config or Code Example
Before
<script src="https://example.com/script.js"></script>After
<script src="https://example.com/script.js" integrity="sha256-YOUR_BASE64_ENCODED_HASH" crossorigin="anonymous"></script>4.4 Security Practices Relevant to This Vulnerability
Several security practices help mitigate this risk. Least privilege limits the impact of a compromised resource, while secure headers add extra protection layers.
- Practice 1: Content Security Policy (CSP) can restrict which resources your site loads, reducing reliance on third parties and limiting attack surfaces.
- Practice 2: Regularly review third-party dependencies to ensure they are trustworthy and haven’t been compromised.
4.5 Automation (Optional)
Automating this process is complex but possible with scripting. Be cautious when modifying HTML files automatically.
#!/bin/bash
# Example script - use with caution! Back up your site first.
find /path/to/your/website/files -name "*.html" -print0 | while IFS= read -r -d $' ' file; do
if grep -q 'src="[^"]*" integrity=' "$file"; then
echo "Skipping $file, SRI already present."
else
# Add logic to download resource, calculate hash, and add integrity attribute.
echo "Adding SRI to $file (implementation omitted for brevity)."
fi
done5. Verification / Validation
Confirm the fix by inspecting the source code again. Check that the `integrity` attributes are present and correct. Test loading the page in a browser to ensure resources load without errors.
- Post-fix check: View the source code of a webpage and verify the presence of the `integrity` attribute on all external script and link tags.
- Re-test: Re-run the quick check (step 3) to confirm that no missing SRI attributes are found.
- Monitoring: Monitor browser console logs for errors related to resource loading failures due to invalid SRI hashes.
grep -r 'src="[^"]*" integrity=' /path/to/your/website/files | wc -l # Expect a non-zero count6. Preventive Measures and Monitoring
Update security baselines to include SRI requirements. Implement checks in your CI/CD pipeline to enforce this policy.
- Baselines: Update your website security baseline or hardening guide to require SRI for all third-party resources.
- Pipelines: Integrate SAST tools into your CI/CD pipeline to scan for missing SRI attributes during development and deployment.
- Asset and patch process: Review external dependencies regularly (e.g., quarterly) to assess their security posture and ensure continued trust.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 1: Incorrect hash values can cause external resources to fail to load, breaking website functionality.
- Risk or side effect 2: Changes to the third-party resource require updating the SRI attribute in your HTML files.
- Roll back: Revert the changes made to the HTML files to remove the added `integrity` attributes. Restore from backup if necessary.
8. References and Resources
- Vendor advisory or bulletin: N/A – This is a general web security practice, not specific to one vendor.
- NVD or CVE entry: N/A – No specific CVE for missing SRI in isolation.
- Product or platform documentation relevant to the fix: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity