Vulnerability Reward Program

Program Rules

On November 2010, our security team launched
a Vulnerability Reward Program for Google web properties. We have long enjoyed
close cooperation with the security research community - and encouraged by the
success of our Chrome
Vulnerability Reward Program, we decided to take this step to invite
cutting-edge external research that would help us keep our users safe.

Services in scope

Any Google-operated web service that handles reasonably sensitive user data is intended
to be in scope. This includes virtually all the content in the following domains:

*.google.com

*.youtube.com

*.blogger.com

*.orkut.com

We make an important exception for acquired companies: for the first 6 months after the
acquisition, the vulnerabilities in acquired platforms will usually not qualify for a
reward.

Please note that Google client applications (Android, Picasa, Google Desktop, etc) are
currently not in scope. We may expand the program in the future.

Qualifying vulnerabilities

It is difficult to provide a definitive list of bugs that will qualify for a reward: any
bug that substantially affects the confidentiality or integrity of user data is likely to
be in scope for the program. Common examples include:

Cross-site scripting

Cross-site request forgery

Cross-site script inclusion

Flaws in authentication and authorization mechanisms

Server-side code execution or command injection bugs.

The following reports will be definitely excluded:

Attacks against Google corporate infrastructure

Social engineering and attacks on physical facilities

Brute-force denial of service bugs

SEO techniques

Vulnerabilities in non-web applications

Vulnerabilities in Google-branded services operated by third parties.

Out of concern for the availability of our services to all users, we ask you to refrain
from using any tools that are likely to automatically generate significant volumes of
traffic.

Reward amounts

Rewards for qualifying bugs range from $100 to $20,000. The following table outlines the
usual rewards for the anticipated classes of bugs:

[2] Note that acquisitions qualify for a reward only after the initial 6 month
blackout period has elapsed.

In each case, the ultimate decision is made by the reward panel and is at our discretion.
In particular, we may decide to pay higher rewards for unusually clever or severe
vulnerabilities; decide that a single report actually constitutes multiple bugs; or that
multiple reports are so closely related that they only warrant a single reward.

We understand that some of you are not interested in money. We also offer the option to
donate your reward to charity. If you do, we will match it - subject to our discretion.

Regardless of whether you're rewarded monetarily or not, all vulnerability reporters who
interact with us in a productive manner will be credited on the Hall of Fame. If we file a
security bug internally, we will acknowledge your contribution on that page.

Investigating and reporting bugs

When investigating a vulnerability, please, only ever target your own accounts. Never
attempt to access anyone else's data, and do not engage in any activity that would be
disruptive or damaging to your fellow users or to Google.

If you have found a vulnerability, please contact us at security@google.com. Feel free to be succinct: the
mailbox is attended by security engineers, and a short proof-of-concept link is more
valuable than a video explaining the consequences of an XSS bug. Oh: if necessary, you
can use this PGP key.

Note that we are only able to answer to technical vulnerability reports. Non-security
bugs and queries about problems with your account should be instead directed to Google Help Centers.

Q: What happens if I disclose the bug publicly before you had a chance to fix
it?

A: Please read our stance on
coordinated disclosure. In essence, our pledge to you is to respond promptly and fix
bugs in a sensible timeframe - and in exchange, we ask for a reasonable advance notice.
Reports that go against this principle will usually not qualify, but we will evaluate
them on a case-by-case basis.

Q: I wish to report an issue through a vulnerability broker. Will my report still
qualify for a reward?

A: We believe that it is against the spirit of the program to privately disclose the flaw
to third parties for purposes other than actually fixing the bug. Consequently, such
reports will typically not qualify.

Q: What if somebody else also found the same bug?

A: First in, best dressed. You will qualify for a reward only if you were the first
person to alert us to a previously unknown flaw.

A: Sure. If you are selected as a recipient of a reward, and if you accept, we will need
your contact details to process the payment. You can still request not to be listed on
our public credits page, however.

Q: Are there any commonly reported vulnerabilities that are not clear-cut, and for
which the panel historically erred on the side of not issuing rewards?

A: Yes. In the spirit of transparency, and to help focus external efforts, here is an
overview of reports we most commonly reject:

Vulnerabilities in Google-branded services maintained by third
parties: There is a small number of (typically minor) Google-branded sites
operated by external companies: for example, Google Store is operated by Merchandise Mania. For obvious reasons, we
cannot authorize you to test such servers on behalf of these companies - and
therefore, we regrettably can’t consider any eventual reports as in scope for our
reward program.

Before getting started with any security testing, we ask you to confirm that the
service is actually operated by Google: examining WHOIS and DNS records, and reading
the fine print on the target page itself, should offer sufficient insight.

Cross-site scripting vulnerabilities in “sandbox” domains: Google
maintains a number of “sandbox” domains designed specifically to take benefit of
the same-origin
policy to securely isolate certain classes of untrusted content and keep it
completely separate from sensitive google.com interfaces. The two most prominent examples
of this are googleusercontent.com and gmodules.com.

The panel will usually deem reports of script execution vectors in these domains to
be non-qualifying, unless it can be demonstrated that the design directly jeopardizes
the security of any sensitive user data.

URL redirection: Some members of the security community argue that
open redirectors are a security issue. The common argument in favor of this view is
that some users, when presented with a carefully crafted link, may be duped into
thinking that they will be taken to a trusted page - but will be not be attentive
enough to examine the contents of the address bar after the redirection takes place.

On the other hand, we recognize that the address bar is the only reliable security
indicator in modern browsers; and consequently, we think that any user who could be
misled by a URL redirector can also be tricked in other ways, without relying on any
particular trusted website to act as a relying party.

The reward panel will likely deem URL redirection reports as non-qualifying: while we
prefer to keep their numbers in check, we hold that the usability and security
benefits of a small number of well-implemented and carefully monitored URL
redirectors tend to outweigh the true risks.

Legitimate content proxying and framing: The panel applies similar
reasoning to most cases of content proxying and framing - for example, to page
previews in Google Image Search and Google Translate, cached page views in Web
Search, and user-created gadgets on iGoogle.

In general, we expect our services to label third-party content unambiguously and to
perform a number of malware and abuse detection checks. However, we recognize that
well-implemented content proxying brings innovative and unique functionality to many
of our user-oriented services, and similarly to URL redirection, we believe that
usability benefits substantially outweigh the risks.

When it comes to framed third-party content, we recognize that framebusting is an interesting – and
still unsolved – vector for petty mischief. To that effect, Google actively
participates in efforts to rework the browser frame model – e.g., through the
proposed HTML5
sandbox attribute. That said, as with many other architectural improvements
attempted today, it will be a while before this problem is fully eradicated.

Execution of owner-supplied JavaScript on Blogger: Blogger users are
permitted to place custom JavaScript in their own blog templates and blog posts; our
take on this is that blogs are user-generated content, not different from any
third-party website on the Internet. Naturally, for your safety, we do employ spam
and malware detection technologies - but we believe that the flexibility in managing
your own content is essential to the success of our blogging platform.

Therefore, the ability to execute owner-supplied scripts on your own blog is not
considered to be a vulnerability. The ability to inject arbitrary JavaScript onto
somebody else’s blog would likely qualify for a reward, however!

Logout cross-site request forgery: At this time, the ability of
malicious web sites to log users out of unrelated web applications is essentially
unavoidable; it is a consequence of how the web is designed, and cannot be reliably
prevented by any single website. You might be interested in the following personal
blog posts published a while ago on this topic by two panel members:

Consequently, in most cases, the panel will not consider reports of the ability to
log out users from Google as qualifying for the reward. Difficult, long-term
browser-level improvements are required to truly eliminate this possibility.

Flaws present only when using out-of-date browsers and plugins: The
security model of the web is being constantly fine-tuned and improved by the vendors
and by the security community. The panel will typically not reward reports of
vulnerabilities that affect only the users of outdated or unpatched browsers. In
particular, as of April 2012, we have decided to exclude Internet Explorer versions
prior to 8.

Legal points

We are unable to issue rewards to individuals who are on sanctions lists, or who are in
countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. You are
responsible for any tax implications depending on your country of residency and
citizenship. There may be additional restrictions on your ability to enter depending upon
your local law.

This is not a competition, but rather an experimental and discretionary rewards program.
You should understand that we can cancel the program at any time, and the decision as to
whether or not to pay a reward has to be entirely at our discretion.

Of course, your testing must not violate any law, or disrupt or compromise any data that
is not your own.