Web Application Security Assessment: Cross-Site Scripting

In the Cross-Site Scripting assessment for Web Application Security, 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.

API: GET Web Application Security Evidence: Cross-Site Scripting [/v1/companies/company_guid/findings?risk_vector=web_appsec]

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.

Certain scripts cannot have the integrity attribute set. See excluded scripts.

Finding Message: Missing integrity attribute

Grading & Conditions

Subresource integrity (SRI) checks ensure that resources loaded on a web page have not been tampered with. This is not a common security measure since 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 a complex security measure to implement, 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.

Minimum weight: -0.3 ❖

Maximum weight: 0.1

Possible Grades:

Weight = ≤0

Condition = A relevant number of SRI checks are implemented.

Weight = Between >0 and ≤0.1

Condition = Very few (or zero) SRI checks are implemented.

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.

Finding Message: Invalid Subresource Integrity (SRI) digest

Grading & Conditions

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.

Minimum weight: 0

Maximum weight: 50

Possible Grades:

Weight = 0

Weight = Between ≥10 and ≤50

Condition = This website contains an invalid digest for at least one resource being loaded outside of the web application's origin.

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.

Finding Message: An insecure CSP configuration was detected.

Grading & Conditions

Web applications are graded based 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.

Minimum weight: 0

Maximum weight: 0.1

Possible Grades:

Weight = 0

Condition = The CSP policy has no issues.

Weight = Between >0 and ≤0.1

Condition = No CSP policy was found or the CSP has some issues that make it ineffective.

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 attributes such as unsafe-eval and unsafe-inline in object-src and script-src directives, except in script-src for retrocompatibility if a nonce or hash is also defined.
• Avoiding typos or otherwise invalid CSP directives.
• Avoiding wildcards, host-based allow lists, and bare URL schemes such as HTTP in source directives.

Additionally, consider evaluating the CSP policy using an online tool such as csp-evaluator or Google Chrome’s Lighthouse tool to identify common mistakes or bad practices.

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

Finding Message: Resource blocked by Content Security Policy (CSP)

Grading & Conditions

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.

Minimum weight: 0

Maximum weight: 100

Possible Grades:

Weight = 0

Condition = No CSP violations were found.

Weight = Between ≥10 and ≤100

Condition = At least one unique CSP violation was found.

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.