Remediating Web Security Scanner findings

This page explains how to interpret, reproduce, and remediate Web Security Scanner findings.

The IAM roles for Security Command Center can be granted at the organization, folder, or project level. Your ability to view, edit, create, or update findings, assets, and security sources depends on the level for which you are granted access. To learn more about Security Command Center roles, see Access control.

Vulnerability classes

Web Security Scanner detects the following classes of vulnerabilities:

  • Cross-site scripting (XSS)
  • Server-side request forgery
  • Flash injection
  • Mixed-content
  • Outdated or vulnerable libraries
  • Clear text passwords
  • Insecure origin validation
  • Invalid headers
  • Misspelled headers
  • Accessible repositories
  • SQL injection
  • XML injection
  • Prototype pollution

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.

Deactivation of findings after remediation

After you remediate a vulnerability, Web Security Scanner does not automatically set the state of the corresponding Security Command Center finding to INACTIVE. Unless you change the state manually, the state of findings that are generated by Web Security Scanner in Security Command Center remain ACTIVE.

If you are using the standalone version of Web Security Scanner, after you remediate a vulnerability and Web Security Scanner can no longer detect it, subsequent vulnerability reports do not include the vulnerability. A record of the vulnerability remains in the past vulnerability reports.

Web Security Scanner runs managed scans weekly.

For more information about Web Security Scanner scans, see Scan types.

Remediating Web Security Scanner findings

This section explains how to remediate different types of Web Security Scanner findings. For strategies to defend against common application-level attacks that are outlined in OWASP Top 10, see OWASP Top 10 mitigation options on Google Cloud.

XSS

Category name in the API: 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 issue. The recommended fix is to escape all output and use a templating system that supports contextual auto-escaping.

XSS angular callback

Category name in the API: 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

Category name in the API: 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.

Server side request forgery

Category name in the API: SERVER_SIDE_REQUEST_FORGERY

A SERVER_SIDE_REQUEST_FORGERY vulnerability lets a web application user gain access to internal data by forcing a server to make a request (like an HTTP request) to a restricted service endpoint. For example, an attacker can exploit this vulnerability to retrieve data from the Google Cloud metadata service.

To fix this issue, use an allowlist to limit the domains and IP addresses that the web application can make requests to.

Rosetta flash

Category name in the API: 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 was 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

Category name in the API: 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 users.

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

Outdated library

Category name in the API: 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 the version against a known list of vulnerable libraries. False positives are possible if the version detection fails or if the library has been manually patched.

To fix this issue, update to a known secure version of the included library.

Struts insecure deserialization

Category name in the API: STRUTS_INSECURE_DESERIALIZATION

Web Security Scanner might find that your web application is using an Apache Struts version that is vulnerable to remote command injection attacks. The affected Struts versions can incorrectly parse an attacker's invalid Content-Type HTTP header. This vulnerability allows the malicious commands to be executed under the privileges of the web server.

The following are the vulnerable Apache Struts versions:

  • 2.3.x versions earlier than 2.3.32
  • 2.5.x versions earlier than 2.5.10.1

To fix this issue, upgrade Apache Struts to the latest version.

For more information on the Apache Struts vulnerability, see CVE-2017-5638.

Cacheable password input

Category name in the API: CACHEABLE_PASSWORD_INPUT

Web Security Scanner might find that for a password input, the web application uses an <input> element that doesn't have the type attribute set to password. This can cause browsers to cache the user-entered password in the regular browser cache instead of a secure password storage.

To fix this issue, in the <input> element, add the type attribute and set it to password—for example, <input type="password">. This attribute obscures the characters that the user enters in the password field.

Clear text password

Category name in the API: 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.

Insecure allow origin ends with validation

Category name in the API: INSECURE_ALLOW_ORIGIN_ENDS_WITH_VALIDATION

Web Security Scanner might find that a cross-site HTTP or HTTPS endpoint validates only a suffix of the Origin request header before reflecting it inside the Access-Control-Allow-Origin response header. If validation is misconfigured, the endpoint might grant access to a malicious domain that has the same suffix as an allowlisted domain. For example, if the endpoint's validator matches domains like *google.com, it might erroneously grant access to maliciousdomaingoogle.com.

To fix this issue, validate that the expected root domain is part of the Origin header value before reflecting it in the Access-Control-Allow-Origin response header. For subdomain wildcards, prepend the dot to the root domain—for example, .endsWith(".google.com").

Insecure allow origin starts with validation

Category name in the API: INSECURE_ALLOW_ORIGIN_STARTS_WITH_VALIDATION

Web Security Scanner might find that a cross-site HTTP or HTTPS endpoint validates only a prefix of the Origin request header before reflecting it inside the Access-Control-Allow-Origin response header. If validation is misconfigured, the endpoint might grant access to a malicious domain that has the same prefix as an allowlisted domain. For example, if the endpoint's validator only checks if the requesting domain contains google.com, it might erroneously grant access to google.com.maliciousdomain.com.

To fix this finding, validate that the expected domain fully matches the Origin header value before reflecting it in the Access-Control-Allow-Origin response header—for example, .equals(".google.com").

Session ID leak

Category name in the API: SESSION_ID_LEAK

Web Security Scanner might find a session identifier in the Referer request header of your web application's cross-domain requests. Domains receiving the Referer can use the session identifier to impersonate a user (by using their token) or uniquely identify the user.

To fix this finding, store session identifiers in cookies, instead of the URL. In addition, secure your cookies using the following attributes:

  • HTTPOnly: an attribute that makes cookies inaccessible to client-side scripts
  • Secure: an attribute that makes cookies transmissible through HTTPS only

Invalid content type

Category name in the API: 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 issue, ensure the following:

  • 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

Category name in the API: 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

Separate options with semicolons, for example 1; mode=block; report=URI. Make sure that you don't have a trailing semicolon.

Misspelled security header name

Category name in the API: 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

Category name in the API: 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 issue, 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.

XXE reflected file leakage

Category name in the API: XXE_REFLECTED_FILE_LEAKAGE

Web Security Scanner might find an XML External Entity (XXE) vulnerability on a web application that parses XML from user inputs. An attacker can provide an XML that contains an external entity. This external entity can reference content that the application has access to—for example, files on the application's host machine. When the application's XML parser processes the malicious XML, it can leak the contents of files on its host.

To fix this finding, configure your XML parsers to disallow external entities.

For more information on this vulnerability, see XML External Entity (XXE) Processing.

SQL injection

Category name in the API: SQL_INJECTION

Web Security Scanner might find an SQL injection vulnerability. Attackers can create inputs that manipulate the query structure of the underlying SQL query running on the server. These inputs let them exfiltrate data from the database and, in some cases, modify data. To resolve this finding, use parameterized queries to prevent user input from influencing the structure of the SQL query.

For more information on this vulnerability, see SQL Injection.

Prototype pollution

Category name in the API: PROTOTYPE_POLLUTION

Web Security Scanner might find a prototype pollution vulnerability on a web application whose object properties are assigned attacker-controllable values. Attackers can create inputs that make the application vulnerable to cross-site scripting or other client-side vulnerabilities.

To fix this finding, delete the deprecated proto property and make the Object.prototype object immutable. If this mitigation is incompatible with your code, change the vulnerable code portion to only copy expected values from attacker-controllable inputs.

Verify the issue

When Web Security Scanner reports an issue, you need to verify the issue's location. This section explains how to use finding reports to reproduce and verify vulnerabilities.

  1. Go to the Web Security Scanner page in the Google Cloud console.

    Go to Web Security Scanner

  2. Select a project. A page appears with a list of your managed and custom scans.

  3. Under Scan configs, select the scan that contains the finding you want to verify. A page opens with details for the scan.

  4. Navigate to the Results tab, expand a category, and select a finding to see its details.

  5. The verification method differs based on the finding category. Use a test browser and follow the instructions below.

    • Cross-site scripting: Following the Reproduction URL produces an empty popup in the browser, indicating the scan successfully injected benign code into a script.
    • Outdated library: Following the Vulnerable URL returns a page with the text "Exploited," indicating the scan successfully injected benign code into a script.
    • Mixed content Following the URL of the HTTPS page returns a warning about a mixed content vulnerability. The finding report identifies the vulnerable resource under URL of the resource served over HTTP.
    • Flash injection: Web Security Scanner may return findings in this category, but most modern browsers are protected against flash injection. It is unlikely that these findings can be exploited.
    • Prototype pollution: Follow the URL in the Reproduction URL field and search for changes on the Object.prototype object introduced by the payload, with the following JavaScript snippets.
      • ({}).__secret_injected_property
      • ({}).__defineGetter__.__secret_injected_property
      • ({}).hasOwnProperty.__secret_injected_property

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.