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 framingSAMEORIGIN
: allow framing if the top-level URL is same originALLOW-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 XSSreport=URL
sends reports toURL
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.
Go to the Web Security Scanner page in the Google Cloud console.
Select a project. A page appears with a list of your managed and custom scans.
Under Scan configs, select the scan that contains the finding you want to verify. A page opens with details for the scan.
Navigate to the Results tab, expand a category, and select a finding to see its details.
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.