Vulnerability Reward Program - Google Corporate Information

Vulnerability Reward Program

Qualifying bugs

In response to our recently announced web vulnerability reward program, we received a number of excellent, qualifying reports from quite a few members of the information security community.

That said, we have also received multiple reports pertaining to issues that, in the opinion of our reward panel, do not meet the criteria outlined in the original announcement. In the spirit of transparency and to help focus external efforts, we wanted to summarize them here, and explain the reasoning behind our decisions.

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.

Vulnerabilities in recent acquisitions

As indicated in our original announcement, we opted to exclude recent acquisitions from the scope of the reward program in most cases. There are two reasons for this: firstly, newly acquired products are already receiving intense scrutiny from our internal security team as a part of our onboarding process; and secondly, shortly after the acquisition is finalized, Google may simply opt to discontinue certain acquired products, to migrate them to Google technologies, or to rewrite them from scratch, potentially making the issue moot.

The panel agreed to set a self-imposed deadline of 6 months as the upper bound for this criteria; reports pertaining to newer acquisitions will be rewarded only in rare, high severity cases.

Execution of owner-supplied JavaScript on Blogger

Blogger users are permitted to place non-Google as well as Google JavaScript in their own blog templates and blog posts; our take on this is that blogs are user-generated content, in the same way that a third party can create their own 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.

The ability to inject arbitrary JavaScript onto somebody else’s blog would likely qualify for a reward, however!

Note: when evaluating the security of blogspot.com, keep in mind that all the account management functionality – and all the associated HTTP cookies – use separate blogger.com and google.com domains.

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:

• “Logout XSRF – significant web app bug?” (Chris Evans)
• “HTTP cookies, or how not to design protocols” (Michal Zalewski)

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.

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 domains in this class are:

• googleusercontent.com
• gmodules.com

The content in these domains is further compartmentalized and protected depending on product requirements; in some of the application-specific subdomains, it is by design possible to serve arbitrary HTML or JavaScript.

The panel will deem most of the XSS reports for “sandbox” domains to be non-qualifying. We will consider exceptions for any case where it can be demonstrated that the injected content directly jeopardizes sensitive functionality in other Google products, though.

URL redirection

URL redirection is considered a vulnerability by some members of the security community. The most prevalent argument made in support 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 - and will be not be attentive enough to examine the contents of the address bar after the navigation takes place.

That said, it is important to recognize that the address bar is the only reliable content origin indicator available in modern browsers - and therefore, the behavior that would enable URL redirection attacks is inherently unsafe. The panel believes that any user who could be misled by a URL redirector can also be tricked without relying on any particular trusted website to act as a relying party; eliminating URL redirectors will not change this outlook appreciably.

Consequently, 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 perceived risks.

Content proxying and framing

The panel applies similar reasoning to most cases of content proxying and framing — for example, page previews in Google Image Search and Google Translate, cached page views in Web Search, and user-created gadgets for 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 perceived 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.

via google.com