Google Cloud-based Web App Vulnerability Scanner and Assessment Tool releasesd

Google Cloud Security Scanner

Beta

This is a Beta release of the Google Cloud Security Scanner. This API is not covered by any SLA or deprecation policy and may be subject to backward-incompatible changes.

1. How to use the Security Scanner
2. Usage Caveats
3. Pricing, costs, and traffic
4. Limiting scan URLs
   1. Excluding URLs from a scan
5. Preventing unintended consequences
   1. If you use a test account
6. Impact of Security Scanner on logs
7. Vulnerability detection
   1. Cross-site scripting
   2. Mixed Content
   3. List of custom detectors
8. Identifying issues

The Google 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. Only regular App Engine instances are supported.You cannot use the Security Scanner with App Engine Managed VMs, Google Compute Engine, or any other resources.

The scanner complements your existing secure design and development processes. It does not replace a manual security review, and it does not guarantee that your application is free from security flaws. The scanner minimizes false positives, so it will not find every possible type of vulnerability. For more information on web security, see the OWASP Top Ten Project.

Note: Google may use aggregated and anonymized data to improve the performance of the scanner and to analyze web vulnerability trends. Google will not share information on specific issues or the security state of a scanned website with any third party.

How to use the Security Scanner

Before using the scanner on a project, you'll want to read the rest of the material on this page for practical considerations that will provide you with the best experience. In particular, you should pay close attention to the material under Preventing unintended consequences.

That said, here's how you'd use the scanner on a project:

1. Log in as an owner or developer of the App Engine instance to be scanned.
2. Visit the Google Developers Console and select the project. (It must have an App Engine application already deployed.)
3. Select Compute > App Engine > Security scan.
4. The first time you scan your application, you'll be prompted to create a new scan:
   
5. Click Create scan to display the new scan form:
   
   For more information on setting up a scan, see Getting Started.
   Note: If you have scanned your app before, you won't be prompted to create a new one; instead, just use the existing scan. Or, if you need a scan with different settings, create a new scan using the form shown above.
6. To run a scan, make sure the desired scan is selected, then click Run scan:
   

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.

Pricing, costs, and traffic

There is no charge for using the scanner. However, using the scanner impacts App Engine instance quota limits, bandwidth (traffic) charges, and quotas for API calls to App Engine services, such as mail, search, etc. The actual amount of traffic generated from a scan depends on the application and the number of URLs, event handlers, forms, and parameters.

The scanner is optimized to keep traffic to a minimum. By default, the scan rate is throttled to approximately 15 queries per second (QPS), with slight variations in the rate due to the asynchronous nature of many web applications. Currently, a large scan stops after 100,000 test requests, not including requests related to site crawling. (Site crawling requests are not capped.)

Limiting scan URLs

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

Important: Attempting to subvert or in any way direct traffic to out-of-scope URLs is a violation of the acceptable use policy.

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.

Excluding URLs from a scan

If you want to avoid testing sections of a site a scan, you can specify one or more excluded URL patterns. The scanner will not request resources that match any of the exclusions. See the table in the Getting Started page for example URL exclusions.

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 App Engine project and loading your application and data there. If you use gcloud, 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.
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 usingaddEventListener, or attached by setting the appropriate event handler property.
4. Use backup data. Make a backup copy of all your data before scanning, then restore the backup data when you're done. If you use this approach, be sure that no actual users are on the system during the test, because their actions may be overridden when the backup is restored.
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 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.

Vulnerability detection

The Security Scanner tests for cross-site scripting vulnerabilities, mixed content, and certain other custom conditions described in the following sections.

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.

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.

List of custom detectors

The enabled detectors and their firing conditions are listed here:

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.

Identifying issues

If 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 repro 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 repro command as follows:
   open -n /Applications/Google\ Chrome.app/ --args --disable-xss-auditor --user-data-dir=/tmp/xssrepro

Important: Since this browser instance will have XSS and other safety measures disabled, don’t use it for anything other than testing your own security issues!

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies.