Web Application Security Assessment: Cross-Site Scripting

⇤ How is the Web Application Security Risk Vector Assessed?

In this assessment, we validate security measures such as Subresource Integrity (SRI) and content security policies (CPSs) to ensure no malicious remote resources are included in a web application.

Table of Contents

• Framework References
• Cross-Domain Subresource Integrity Check
• Cross-Domain Subresource Integrity Failure
• Content Security Policy Configurations
• Content Security Policy Violations

Framework References

Cross-Domain Subresource Integrity Check

The page does not include an integrity attribute on cross-domain fetching of scripts.

Grading

SRI checks ensure that resources loaded on a web page have not been tampered with. This is an optional security measure; its implementation can be complex and may not be necessary in all cases (e.g., when resources are loaded from within the same origin).

Because this is an optional security measure, we calculate a grade per website that reflects how thoroughly cross-domain dynamic resources are being protected by SRI checks.

For each website scanned, we check all external resources that are loaded and add a single finding. We assign a value of -1 when we determine that a valid SRI check is present and 0.1 when it is missing; the final grade for the finding is calculated using the sum of these values.

Mitigation

If possible, website owners should avoid loading scripts from third-party resources. This avoids exposure to content and JavaScript manipulation by third parties or in the case of a network compromise. If third-party script loading is unavoidable, Subresource Integrity tags should be used whenever possible.

Cross-Domain Subresource Integrity Failure

We detect that a cross-domain fetched script's hash does not match the provided integrity value. This usually means that the resource was modified without the knowledge of the website owner, potentially with malicious intent.

Grading

SRI checks allow website owners and website visitors to ensure that resources that are loaded match what was originally intended and were not manipulated. A failure means that the resource was modified without the knowledge of the website owner.

Mitigation

SRI check failures indicate a potential compromise of third-party resources and should be mitigated immediately. Modern browsers will prevent the affected resources from loading.

Website owners should review their third-party resources for changes and identify any malicious changes that may have been added. If this was a legitimate change, website owners should update the digests on their website to reflect the newly updated resources.

Content Security Policy Configurations

A properly configured CSP can help prevent cross-site scripting (XSS) attacks by restricting the origins of JavaScript, CSS, and other potentially dangerous resources.

A good CSP should:

• Implement directives that set valid source restrictions from where the client can load frames and scripts as well as limit where the client can submit form data.
• Restrict plugins and specify a valid resource for reporting policy violations.
• Not contain “unsafe” keywords or include wildcards that are ineffective for restricting sources.

In this assessment, we focus on the most important objective of a good CSP: preventing cross-site scripting and dynamic content injection attacks.

Grading

Web applications are graded GOOD, FAIR, WARN, or BAD depending on the number and type of issues identified in our assessment.

We perform a series of checks to assess the health of the defined CSP for each website. We use the same engine (csp-evaluator) that is used by Google Chrome’s Lighthouse feature to evaluate CSPs.

Our assessment makes the following checks:

You can review how the final score is calculated for each website below, presented in pseudo-code:

weight <- 0
findings <- [list of findings for this CSP]

# the intermediate score is the score from the type 1 
# findings that have max weight 
weight <- max_weight(get_type_1_findings(findings))

# Additionally, we add the weights of all type 2 findings
for finding in get_type_2_findings(findings):
   weight <- weight + weight(finding)  
final_weight <- weight

The final weight is converted into a finding grade using this table:

Mitigation

Review the CSP of each website such that it is effective in meeting the security objectives it defines, such as:

• preventing unauthorized content resources and scripts from loading
• preventing clickjacking and other nested frame attacks
• ensuring that web forms and links are behaving as intended

This assessment focuses on preventing Cross-Site Scripting attacks. To obtain a better grade, consider:

• implementing directives that set valid and complete source restrictions for loading dynamic content (script-src, object-src, default-src)
• avoiding the use of unsafe directives such as unsafe-eval and unsafe-inline
• avoiding typos or otherwise invalid CSP directives
• avoiding wildcards, host-based allow lists, and bare URL schemes such as HTTP in source directives

Content Security Policy Violations

Browsers generate an error when a webpage contains content that violates the page’s CSP. The presence of such errors suggests that:

• the website content and security policies are incongruent
• the website unknowingly includes third-party content
• malicious code is injected into the website but blocked by the CSP

Grading

To grade these findings, we count the number of unique CSP violation messages per website. We exclude “Report Only” messages, which are usually a sign that website owners are testing new configurations.

These findings are graded according to the following criteria:

Mitigation

Website owners should review their sites for CSP violation messages, as these are usually a sign that the site is attempting to load unknown or unvetted external resources, putting the site at risk.