Identification of Subresource Integrity (SRI) Not Used

Identifying instances where Subresource Integrity (SRI) is not used involves examining how external resources (such as scripts, stylesheets, or fonts) are included within the web application and ensuring that SRI is implemented where appropriate. SRI helps protect against attacks such as content injection and code tampering by ensuring that the fetched resource has not been maliciously modified. Here's how you can identify if SRI is not used:

Identification

  1. Reviewing External Resource Inclusions: Examine how external resources are included within the web application, such as <script>, <link>, or <img> tags, or through JavaScript dynamic loading.
  2. Checking for Integrity Attributes: Look for the integrity attribute in the HTML tags that reference external resources. The integrity attribute is used to specify the cryptographic hash of the resource's content.
  3. Analyzing External Resource URLs: Check if the URLs of external resources are protocol-relative (//) or use the http:// protocol. These URLs may indicate that SRI is not implemented because SRI requires the use of HTTPS.
  4. Testing with SRI Checker Tools: Use SRI checker tools or browser developer tools to inspect the integrity of external resources loaded by the web application. These tools can identify whether SRI is implemented and verify the integrity of fetched resources.
  5. Reviewing Content Security Policy (CSP): Check if the web application has a Content Security Policy (CSP) in place and whether it includes directives related to SRI (require-sri-for directive). A CSP can enforce the use of SRI for certain types of external resources.

Examples

  • Example 1: During testing, a penetration tester discovers that the application includes external JavaScript libraries using standard <script> tags without the integrity attribute. This indicates that SRI is not being used to verify the integrity of the scripts.
  • Example 2: The tester finds that the application loads third-party stylesheets using HTTP URLs (http://) without SRI. This exposes the application to risks such as script injection or content modification by attackers.

Mitigation

  1. Implement SRI for External Resources: Add the integrity attribute with the corresponding cryptographic hash to the HTML tags that reference external resources. This ensures that the fetched resources have not been tampered with.
  2. Use HTTPS for External Resources: Ensure that external resources are loaded over HTTPS to prevent interception or modification in transit. SRI is only effective when used with HTTPS.
  3. Automate SRI Implementation: Use build tools or content delivery networks (CDNs) that automatically generate SRI hashes for hosted resources. This helps streamline the implementation of SRI across the application.
  4. Enforce SRI with CSP: Configure a Content Security Policy (CSP) with directives that require SRI for loading certain types of external resources. This adds an additional layer of protection against resource tampering.
  5. Regular Security Audits: Conduct regular security audits and vulnerability assessments to identify and address instances where SRI is not used in the web application's external resource references.

By identifying and mitigating instances where SRI is not used, organizations can enhance the security of their web applications and protect against attacks that exploit external resource integrity vulnerabilities.