Using Cloud Security Scanner

Cloud Security Scanner identifies security vulnerabilities in your Google App Engine web applications. It crawls your application, following all links within the scope of your starting URLs, and attempts to exercise as many user inputs and event handlers as possible. The scanner currently detects the following:

  • XSS
  • Flash injection
  • Mixed-content
  • Usage of insecure JavaScript libraries

Cloud Security Scanner currently supports the Google App Engine standard environment instances only. It is not yet enabled for Google App Engine flexible environment, Google Compute Engine, or other Google Cloud resources.

The scanner is designed to complement your existing secure design and development processes. To avoid distracting developers with false positives, the scanner errs on the side of under reporting and will not display low confidence alerts. It does not replace a manual security review, and it does not guarantee that your application is free from security flaws. For more information on web security, see the OWASP Top Ten Project.

Learn more about Google Cloud Platform Security

Usage Caveats

Some important things to be aware of when using this tool:

  • Because the scanner is undergoing continual improvements, a future scan may report issues that are not reported by the current scan.
  • Some features or sections of your application might not be tested.
  • The scanner attempts to activate every control and input it finds.
  • If you expose state-changing actions for which your test account has permission, the scanner is likely to activate them ‒ which may lead to undesirable results.

Who can run a security scan?

See Access Control for details on IAM roles for Cloud Security Scanner.

How much time is required for a security scan?

The security scan does not execute immediately; it is queued and then executes later, possibly hours later depending on system load. Once the scan begins executing, the time it takes will depend on the size of your application size. Large applications with many URLs may take several hours to complete.

Before you scan

Prior to scanning, carefully audit your application for any feature that may affect data, users, or systems beyond the desired scope of your scan.

Because the scanner populates fields, pushes buttons, clicks links, and so on, it should be used with caution. The scanner could potentially activate features that change the state of your data or system, with undesirable results. For example:

  • In a blog application that allows public comments, the scanner may post test strings as comments on all your blog articles.
  • In an email sign-up page, the scanner may generate large numbers of test emails.

For tips on how to minimize risk see Preventing unintended consequences.

Creating a scan

  1. If you haven't created a test account, do so now and then log into the test account. (For information on why you'd want to use a test account, see Preventing unintended consequences.) The test account must be an owner or developer of the Google App Engine instance to be scanned.

  2. Go to the Google Cloud Platform Console

  3. Select a project that already has an Google App Engine application deployed.

  4. Select Compute > App Engine > Security scan.

  5. The first time you scan your application, you'll be prompted to create a new scan:

  6. Click Create scan to display the new scan form, which we show here maximized to reveal all the possible fields:

    Alternatively, if a scan already exists, you won't see the above prompt, but you can click New scan button in the top of the page to display the new scan form.

  7. Fill out the scan fields as desired, using the table below as a guide.

  8. Click Create.

The following table provides information on some of the scan fields.

Field Name or Choice Description
Starting URLs A simple site usually requires only one starting URL ‒ the home, main, or landing page for the site, from which the scanner can find all other site pages. However, the scanner may fail to find all the pages if a site has a large number of pages, or islands of unconnected pages, or if the navigation requires complex JavaScript (such as a mouseover-driven multilevel menu). In such cases, specify additional starting URLs to increase scan coverage.
Excluded URLs To reduce complexity, exclusions are defined using a simplified proto-language using one or more * wildcards, rather than requiring a valid regex. For details and sample valid patterns, see Excluding URLs in Scans.
Google accounts You can create a test account in Gmail and use the account to scan your product. As an alternative, if you are a Google Apps customer you can create test accounts within your domain (e.g., test-account@yourdomain.com). In the scanner, these accounts work like Gmail accounts. (Two factor authentication is not supported.)

Note that Google enforces a real name policy on G+ accounts. Your test account may be blocked from G+ if the name does not look real.
Non-Google accounts Select this option if you do not intend to use Google Account services and have instead created your own authentication system. Specify the login form's URL, the username, and the password. These credentials are used to log into your application and scan it.

Note that support for login forms is still in development, and may not work out-of-the-box with your system. If you have confirmed your test account is able to login manually, but not in Cloud Security Scanner, use the feedback option within the tools to request support.
Schedule You can set the scan to run daily, weekly, fortnightly or every four weeks. We recommend creating a scheduled scan to ensure that future versions of your application are tested. Also, because we occasionally release new scanners that find additional bug types, running a scheduled scan gives you the benefits of the additional coverage without manual effort.

Running a scan

To run a scan:

  1. Make sure you are logged into the test account used to create the scan.

  2. In the Google Cloud Platform Console, select the project for which you've created a scan.

  3. Select Compute > App Engine > Security scan.

  4. If you have created multiple scans for your app, select the desired scan from the list that is displayed. If you created only one scan for this app, the scan is displayed and is ready to run:

  5. Click Run scan to start scanning your app.

The scan is placed in a queue, and there may be a delay before it runs. It may take several minutes or many hours to run, depending on the system load and features like site complexity, number of actionable elements per page, numbers of links, and the amount of JavaScript (including navigation).

Editing and deleting scans

  1. Make sure you are logged into the test account used to create the scan.

  2. In the Google Cloud Platform Console, select the project for which you've created a scan.

  3. Select Compute > App Engine > Security scan.

  4. If you have created multiple scans for your app, select the desired scan from the list that is displayed. If you created only one scan for this app, the scan is displayed and is ready for editing or deletion:

  5. Click Edit to edit the scan or Delete to delete it from your project.

Check the scan page for status and results of the scan. You may also find helpful information in the project log page Logs page

Result details

Cloud Security Scanner detects four classes of vulnerabilities: XSS, Flash injection, mixed-content, and usage of insecure Javascript libraries. If any of these are found, then the result is highlighted for you to explore in detail.

Cross-site scripting

The scanner's cross-site script (XSS) injection test simulates an injection attack by inserting a benign test string into user-editable fields and performing a variety of 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 will start the Chrome debugger.

An example of an XSS alert in the vulnerable parameter q=

Because the test string was able to execute we now know that injecting and running JavaScript on this page is possible. If an attacker found this issue they would be able to execute JavaScript of their choosing as the user (victim) who click on a malicious link.

In some circumstances, the application under test might modify the test string before it is parsed by the browser. For example, the application might validate the input or limit the size of a field. When the browser attempts to runs this modified test string, it will likely break and throw a JavaScript execution error, thus an injection issue is occurring. However, it may not be exploitable. Manual verification is needed to see if the test string modifications can be evaded and confirm that the issue is in fact an XSS vulnerability.

An example of a JavaScript breakage alert indicating that parameter q= may have an injection issue.

There are various ways to fix this problem; however, what we recommend is escaping all output and using a templating system that supports contextual auto-escaping.

Flash injection

The scanner may find a parameter that is reflected back at the beginning of a response. This is also known as Rosetta Flash. Under certain circumstances an attacker may cause the browser to execute the response as if it were a Flash file provided by the vulnerable web application.

Example of a Flash injection alert in the parameter callback=

To fix this, avoid including user controllable data at the start of a HTTP response.

Mixed Content

The 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.

Example of a mixed content alert in HTTPS page attribute_script including a HTTP resource from http://irrelevant.google.com

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

Outdated Library

The scanner may find that the version of an included library is known to contain a security issue. This is a signature-based scanner that attempts to identify the version of 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.

Example of a outdated library alert due to the use of jquery-1.8.1.js

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

Verify the issue

When the scanner reports an issue you'll need to verify the issue's location. Do this with a browser that has XSS protection turned off: we recommend using a separate test instance of Chrome, but any modern browser that allows you to disable XSS protection should work.

To disable XSS protection in Chrome:

  1. 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

  2. If you use Mac OSX, invoke the Chrome command as follows:

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

Note that Content Security Policy (CSP) enforcement might still prevent the Javascript code from running, thus making 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.

Target restrictions

The scanner has filters in place that restrict scan targets to the specific Google App Engine instance for which the scan is created. Entering URLs for a different Google App Engine project or an outside domain will result in an error message.

Within your project, the scanner automatically attempts to avoid logout URLs and other generic locations that may adversely affect a scan. However, to be sure, you can manually exclude URLs via the scan settings.

Preventing unintended consequences

Because the scanner populates fields, pushes buttons, clicks links, and so on, it should be used with caution. The scanner could potentially activate features that change the state of your data or system, with undesirable results.

For example:

  • In a blog application that allows public comments, the scanner may post test strings as comments on all your blog articles.
  • In an email sign-up page, the scanner may generate large numbers of test emails.

Here are some techniques which can be used, separately or in combination, to scan without creating these or other unforeseen consequences:

  1. Run scans in a test environment. Set up a test environment by creating a separate Google App Engine project and loading your application and data there. If you use the gcloud command-line tool, you can specify the target project as a command-line option when uploading your app.
  2. Use a test account. Create a user account that does not have access to sensitive data or harmful operations, and use it when scanning your app. Many applications present a special workflow during a user's first-time login ‒ accepting terms, creating a profile, and so on. Because of the different workflow, a test account for an initial user may yield different scan results than an established user account. We recommend scanning with an account that is in the normal user state; that is, after the first-time flow has been completed.
  3. Block individual UI elements that you do not want activated by applying the CSS class inq-no-click. Event handlers attached to this element are not activated during crawling and testing, regardless of whether they are inline JavaScript, or attached using addEventListener, or attached by setting the appropriate event handler property.
  4. Use backup data. Consider making a backup of your data before scanning.
  5. Excluded URLs. You may specify URL patterns that will not be crawled or tested. Syntax is in the Exclude URLs section.

Prior to scanning, carefully audit your application for any feature that may affect data, users, or systems beyond the desired scope of your scan.

If you use a test account

Many applications present a special workflow during a user's first-time login ‒ accepting terms, creating a profile, and so on. If your application has a different flow for first-time users, bear this in mind when choosing a user account for your scan. Because of the different workflow, a new (i.e., first-time) user account may yield different scan results than an established user account. We recommend scanning with an account that is in the normal user state; that is, after the first-time flow has been completed.

Impact of Cloud Security Scanner on logs

Some traces of the scan will appear in your log files. For instance, the security scanner generates requests for unlikely strings such as "~sfi9876" and "/sfi9876" in order to examine your application's error pages; these intentionally invalid page requests will show up in your logs.

Interpret scan results

The scanner tests and reports the following issues:

Detector Detection condition
XSS DEBUG The Chrome webtools debugger was successfully called via an XSS in the application under test.
XSS ERROR The Chrome javascript parser detected a syntax error caused by the test request.
XSS FLASH INJECTION The application produced a JSONP response where the user can influence the beginning of the response.
MIXED CONTENT Chrome has performed a request to an HTTP script or CSS while in an HTTPS page.
OUTDATED LIBRARY The version of a JS library in use has a known security issue. Note - the issue was not exploited.

For more information see Result details.

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Cloud Security Scanner Documentation