Remediating Web Security Scanner findings

Interpret, reproduce, and remediate Web Security Scanner findings.

Vulnerability classes

Web Security Scanner detects the following classes of vulnerabilities:

  • Cross-site scripting (XSS)
  • Flash injection
  • Mixed-content
  • Clear text passwords
  • Use of insecure JavaScript libraries

If any of these vulnerabilities are found, then the result is highlighted for you to explore in detail.

Impact on logs

Traces of Web Security Scanner scans appear in your log files. For example, Web Security Scanner generates requests for unusual strings like ~sfi9876 and /sfi9876. This process enables the scan to examine your application's error pages. These intentionally invalid page requests appear in your logs.

Remediating Web Security Scanner findings

Following is information about how to remediate different types of Web Security Scanner findings.

XSS

Web Security Scanner cross-site scripting (XSS) injection testing simulates an injection attack by inserting a benign test string into user-editable fields and then performing various user actions. Custom detectors observe the browser and DOM during this test to determine whether an injection was successful and assess its potential for exploitation.

If the JavaScript contained within the test string cleanly executes, it starts the Chrome debugger. When a test string is able to execute, it's possible to inject and run JavaScript on the page. If an attacker found this issue, they could execute JavaScript of their choosing as the user (victim) who clicks a malicious link.

In some circumstances, the application under test might modify the test string before it's parsed by the browser. For example, the application might validate the input or limit the size of a field. When the browser tries to run this modified test string, it is likely to break and throw a JavaScript execution error. The error indicates an injection issue, but it might not be possible to exploit it.

To address this issue, you need to confirm if the issue is an XSS vulnerability by manually verifying if the test string modifications can be evaded. For detailed information about how to verify this vulnerability, see Cross-site scripting.

There are various ways to fix this problem. The recommended fix is to escape all output and use a templating system that supports contextual auto-escaping.

XSS_ANGULAR_CALLBACK

A cross-site scripting (XSS) vulnerability in AngularJS modules can occur when Angular interpolates a user-provided string. Injecting user-provided values into an AngularJS interpolation can allow the following attacks:

  • An attacker can inject arbitrary code into the page rendered by browsers.
  • An attacker can perform actions on behalf of the victim browser in the page's origin.

To reproduce this potential vulnerability, follow the Reproduction URL link in the Google Cloud Console after you run the scan. This link directly opens an alert dialog or injects the string XSSDETECTED to prove that the attack can execute code. If the string is injected, you can open the developer tools of your browser and search for XSSDETECTED to find the exact position of the injection.

XSS_ERROR

An XSS_ERROR finding is a potential XSS bug due to JavaScript breakage. In some circumstances, the application under test might modify the test string before the browser parses it. When the browser tries to run this modified test string, it is likely to break and throw a JavaScript execution error. This error indicates an injection issue, but it might not be possible to exploit it.

To address this issue, you need to confirm if the issue is an XSS vulnerability by manually verifying if the test string modifications can be evaded. For detailed information about how to verify this vulnerability, see Cross-site scripting.

ROSETTA_FLASH

Web Security Scanner might find that the value of a request parameter is reflected back at the beginning of a response, for example, in requests using JSONP. This vulnerability is also known as flash injection. Under certain circumstances, an attacker can cause the browser to execute the response as if it were a Flash file provided by the vulnerable web application.

To fix this issue, don't include user controllable data at the start of an HTTP response.

MIXED_CONTENT

Web Security Scanner passively observes the HTTP traffic and detects when a request for a JavaScript or CSS file is performed over HTTP while in the context of an HTTPS page. In this scenario, a man-in-the-middle attacker could tamper with the HTTP resource and gain full access to the website that loads the resource or to monitor the actions taken by the user.

To fix this issue, use relative HTTP links, for example, replace http:// with //.

OUTDATED_LIBRARY

Web Security Scanner might find that the version of an included library is known to contain a security issue. Web Security Scanner is a signature-based scanner that attempts to identify the version of the library in use and checks this against a known list of vulnerable libraries. False positives are possible if the version detection fails or if the library has been manually patched.

Fix this issue by updating to a known secure version of the included library.

CLEAR_TEXT_PASSWORD

Web Security Scanner might find that the application appears to be transmitting a password field in clear text. An attacker can eavesdrop network traffic and sniff the password field.

To protect sensitive information that passes between client and server, always take the following precautions:

  • Use TLS/SSL certificates.
  • Always use HTTPS on pages that include password fields.
  • Make sure that form action attributes always point to an HTTPS URL.

INVALID_CONTENT_TYPE

Web Security Scanner might find that a resource was loaded that doesn't match the response's Content-Type HTTP header. In this scenario, the application returns sensitive content with an invalid content type, or without an X-Content-Type-Options: nosniff header.

To fix this vulnerability, ensure that:

  • JSON responses are served with the Content-Type header application/json
  • Other sensitive responses are served with appropriate MIME types
  • Serve content with the HTTP header X-Content-Type-Options: nosniff

INVALID_HEADER

Web Security Scanner might find that a security header has a syntax error, resulting in a malformed or invalid valued header. As a result, the browser ignores these headers.

Valid headers are described in the following sections.

Referrer-Policy header

A valid referrer policy contains one of the following values:

  • An empty string
  • no-referrer
  • no-referrer-when-downgrade
  • same-origin
  • origin
  • strict-origin
  • origin-when-cross-origin
  • strict-origin-when-cross-origin
  • unsafe-url

X-Frame-Options header

A valid X-Frame-Options header can only have the following values:

  • DENY: disallow all framing
  • SAMEORIGIN: allow framing if the top-level URL is same origin
  • ALLOW-FROM URL

Chrome does not support ALLOW-FROM URL. Multiple X-Frame-Options are not allowed.

X-Content-Type-Options header

A valid X-Content-Type-Options header can only have one value: nosniff.

X-XSS-Protection header

A valid X-XSS-Protection header must start with either 0 ("disable") or 1 ("enable"). Then, only if you enable the protection, you can add up to two options:

  • mode=block shows a blank page instead of filtering the XSS
  • report=URL sends reports to URL

Options must be separated by semicolons, for example 1; mode=block; report=URI. Make sure that you don't have a trailing semicolon.

MISSPELLED_SECURITY_HEADER_NAME

Web Security Scanner might find a misspelled security header name. In its misspelled form, the security header is ineffective and must be fixed.

To reproduce this vulnerability, check for the misspelling in the network tab of your browser's developer tools.

MISMATCHING_SECURITY_HEADER_VALUES

Web Security Scanner might find that the response has duplicated, security-related response headers with conflicting values. Some security-related HTTP headers have undefined behavior if declared twice in the response with mismatching values.

To fix this vulnerability, keep only one of these mismatching headers.

Accessible repository

Web Security Scanner might find an accessible GIT or SVN repository in the application. This condition can lead to configuration and source code leaks.

To reproduce the vulnerability, click the reproduction URL in the finding report.

Verify the issue

When Web Security Scanner reports an issue, you need to verify the issue's location. Use a browser that has XSS protection turned off. It's best to use a separate test instance of Chrome, but you can use most modern browsers that let you disable XSS protection.

To disable XSS protection in Chrome:

  • If you use Linux, invoke the Linux Chrome command as follows:

    chrome --user-data-dir=~/.chrometest --allow-running-insecure-content \
      --disable-xss-auditor --disable-sync --bwsi
    
  • If you use macOS, invoke the Chrome command as follows:

    open -n /Applications/Google\ Chrome.app/ --args --disable-xss-auditor \
      --user-data-dir=/tmp/xssrepro
    

Content Security Policy (CSP) enforcement might still prevent the JavaScript code from running. This condition can make it more difficult to reproduce the XSS. If you experience this issue, check the browser log console for details about the CSP violation that occurred.