Some of the most interesting security bugs we've fixed have been reported by researchers external to the Chromium project. For example, this same origin policy bypass from Isaac Dawson or this v8 engine bug found by the Mozilla Security Team. Thanks to the collaborative efforts of these people and others, Chromium security is stronger and our users are safer.

Today, we are introducing an experimental new incentive for external researchers to participate. We will be rewarding select interesting and original vulnerabilities reported to us by the security research community. For existing contributors to Chromium security — who would likely continue to contribute regardless — this may be seen as a token of our appreciation. In addition, we are hoping that the introduction of this program will encourage new individuals to participate in Chromium security. The more people involved in scrutinizing Chromium's code and behavior, the more secure our millions of users will be.

Such a concept is not new; we'd like to give serious kudos to the folks at Mozilla for their long-running and successful vulnerability reward program.

Any valid security bug filed through the Chromium bug tracker (under the template "Security Bug") will qualify for consideration. As this is an experimental program, here are some guidelines in the form of questions and answers:

Q) What reward might I get?
A) As per Mozilla, our base reward for eligible bugs is $500. If the panel finds a particular bug particularly severe or particularly clever, we envisage rewards of $1337. The panel may also decide a single report actually constitutes multiple bugs. As a consumer of the Chromium open source project, Google will be sponsoring the rewards.

Q) What bugs are eligible?
A) Any security bug may be considered. We will typically focus on High and Critical impact bugs, but any clever vulnerability at any severity might get a reward. Obviously, your bug won't be eligible if you worked on the code or review in the area in question.

Q) How do I find out my bug was eligible?
A) You will see a provisional comment to that effect in the bug entry once we have triaged the bug.

Q) What if someone else also found the same bug?
A) Only the first report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed bug report in the bug tracker is considered the first report.

Q) What about bugs present in Google Chrome but not the Chromium open source project?
A) Bugs in either build may be eligible. In addition, bugs in plugins that are part of the Chromium project and shipped with Google Chrome by default (e.g. Google Gears) may be eligible. Bugs in third-party plugins and extensions are ineligible.

Q) Will bugs disclosed publicly without giving Chromium developers an opportunity to fix them first still qualify?
A) We encourage responsible disclosure. Note that we believe responsible disclosure is a two-way street; it's our job to fix serious bugs within a reasonable time frame.

Q) Do I still qualify if I disclose the problem publicly once fixed?
A) Yes, absolutely. We encourage open collaboration. We will also make sure to credit you in the relevant Google Chrome release notes and nominate you for the Google Security "thank you" section.

Q) What about bugs in channels other than Stable?
A) We are interested in bugs in the Stable, Beta and Dev channels. It's best for everyone to find and fix bugs before they are released to the Stable channel.

Q) What about bugs in third-party components?
A) These bugs may be eligible (e.g. WebKit, libxml, image libraries, compression libraries, etc). Bugs will be ineligible if they are part of the base operating system as opposed to part of the Chromium source tree. In the event of bugs in a component shared with other software, we are happy to take care of responsibly notifying other affected parties.

Q) Who determines whether a given bug is eligible?
A) The panel includes Adam Barth, Chris Evans, Neel Mehta, SkyLined and Michal Zalewski.

Q) Can you keep my identity confidential from the rest of the world?
A) Yes. If selected as the recipient of a reward, and you accept, we will need your contact details in order to pay you. However — at your discretion, we can credit the bug to "anonymous" and leave the bug entry private.

Q) No doubt you wanted to make some legal points?
A) Sure. We encourage participation from everyone. However, we are unable to issue rewards to residents of countries where the US has imposed the highest levels of export restriction (e.g. Cuba, Iran, North Korea, Sudan and Syria). We cannot issue rewards to minors, but would be happy to have an adult represent you. This is not a competition, but rather an ongoing reward program. 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 local law.

We look forward very much to issuing our first reward and featuring it on our releases blog. We're happy to take questions at [email protected]. Alternatively, feel free to leave a comment. We will update this blog post with answers to any popular questions.

Finally, if you're interested in helping out Chromium security on a more permanent basis, we have open positions.

Posted by Chris Evans, Google Chrome Security
Labels: ,


Strict-Transport-Security

Strict-Transport-Security lets a high-security web site tell the browser that it wants to be contacted over a secure connection only. That means the browser will always use HTTPS to connect to the site and will treat all HTTPS errors as hard stops (instead of prompting the user to "click through" certificate errors). This feature strengthens the browser's defenses against attackers who control the network, such as malicious folks disrupting the wireless network at a coffee shop.

Originally proposed in a research paper in 2008, Strict-Transport-Security is now an open specification. In addition to being in Google Chrome 4, Strict-Transport-Security has also been implemented in NoScript, a security add-on for Firefox, and a native implementation is underway in Firefox. A number of high-security web sites have already started to use the feature, including PayPal. As with all of our security improvements, we hope that every browser will adopt Strict-Transport-Security, making the web, as a whole, more secure.

Cross-Origin Communication with postMessage

The postMessage API is a new HTML5 feature that lets web developers establish a communication channel between frames in different origins. Previously, when you wanted to add a gadget to your web page, you had two options: (1) include the gadget via a script tag, or (2) embed the gadget using an iframe tag. If you used a script tag, you could have a rich interaction with the gadget (e.g., the Google Maps API), but you had to trust the gadget author not to inject malicious script into your web page. Alternatively, if you used an iframe tag to embed the gadget (e.g., the Google Calendar web element), you had strong security properties, but it was difficult to interact with the gadget.

postMessage changes the game. By using postMessage to communicate with the gadget, you get the security advantages of an iframe with all the interactivity of a script tag. What's more, you can use postMessage to create more secure versions of existing gadgets. postMessage is now available in the latest versions of all the major browsers: Google Chrome, Internet Explorer, Firefox, Safari, and Opera. A number of web sites, including Facebook, are already using postMessage to make their site safer.

CSRF Protection via Origin Header

The Origin header is a new HTML5 feature that helps you defend your site against cross-site request forgery (CSRF) attacks. In a CSRF attack, a malicious web site, say attacker.com, instructs the user's browser to send an HTTP request to a target server, say example.com, that confuses the example.com server into performing some action. For example, if example.com is a webmail provider, the CSRF attack might trick example.com into forwarding an email message to the attacker.

The Origin header helps sites defend against CSRF attacks by identifying which web site generated the request. In the above example, example.com can see that the request came from the malicious web site because the Origin header contains the value http://attacker.com. To use the Origin header as a CSRF defense, a site should modify state only in response to requests that either (1) lack an Origin header or (2) have an Origin header with a white-listed value.

The details of the Origin header are still being finalized. We will update the implementation in Google Chrome as the specification evolves based on feedback from Mozilla and from the W3C and IETF communities at large. We welcome your feedback on the last draft of the specification.

ClickJacking Protection with X-Frame-Options

First introduced in Internet Explorer 8, X-Frame-Options is a security feature that lets web sites defend themselves against clickjacking attacks. To defend against clickjacking, a web developer can request that a web page not be loaded inside a frame by including the X-Frame-Options: deny HTTP header. X-Frame-Options is implemented in Google Chrome, Internet Explorer 8, and Safari 4.

Reflective XSS Protection

One of the most difficult parts of building a secure web site is protecting against cross-site scripting (XSS) vulnerabilities. In Google Chrome 4, we've added an experimental feature to help mitigate one form of XSS, reflective XSS. The XSS filter checks whether a script that's about to run on a web page is also present in the request that fetched that web page. If the script is present in the request, that's a strong indication that the web server might have been tricked into reflecting the script.

The XSS filter is similar to those found in Internet Explorer 8 and NoScript. Instead of being layered on top of the browser like those filters, our XSS filter is integrated into WebKit, which Google Chrome uses to render webpages. Integrating the XSS filter into the rendering engine has two benefits: (1) the filter can catch scripts right before they are executed, making it easier to detect some tricky attack variations, and (2) the filter can be used by every WebKit-based browser, including Safari and Epiphany.

We are aware of a few ways to bypass the filter, but, on balance, we think that the filter is providing enough benefit to enable it by default in this release. If you discover a new way to bypass the filter, please let us know. We're very interested in improving the filter in subsequent releases. We're grateful to the security researchers who have helped us with the filter thus far (especially Eduardo "Sirdarckcat" Vela), and we welcome even more participation.

Posted by Adam Barth, Software Engineer


The following screenshots show a browser action's tooltip that has been translated into English, Spanish, Serbian, and Korean.



To localize the extension manifest, extract all user-visible strings into message catalogs, and define the default locale.

{
"name": "__MSG_name__",
"description": "__MSG_description__",
...
"default_locale": "en",
...
}

To get translated messages in JavaScript code, including extension code and content scripts, invoke one of the following forms of chrome.i18n.getMessage().

chrome.i18n.getMessage("messagename")
chrome.i18n.getMessage("messagename", "one parameter")
chrome.i18n.getMessage("messagename", ["one", "to", "nine", "parameters"])

For more details, see the documentation.

We're more than happy to hear your feedback, not only on our implementation and documentation, but also on the API design. You can reach us at the chromium-extensions group.

Posted by Nebojsa Ciric, Software Engineer


Because modality sucks.

Back in 2000, sheets worked well because the smallest unit of user interaction with an application was a window. Soon after, though, things started to change. Web browsers in particular were among the first to start using tabs to put more than one document in a window. This caused a snag. A web page can require modal interaction from the user: picking a file, or supplying a username and password. Yet we don't want to prevent the user from switching to a different tab and continuing to interact with other websites. If the finest-grained modality control we have is per-window, how can we achieve that outcome?

Chromium's current answer comes from combining Cocoa's child window support with sheets to get tab-modal sheets:

While this looks like a normal sheet, you can switch between open tabs while the password request is up. You can't, however, interact with the web page.

The implementation, like all of the code used in Chromium, is open source, and can be found in the Google Toolbox for Mac, a collection of reusable components from the Mac developers at Google. The technical details of the GTMWindowSheetController can be found on the Google Mac blog. The other thing to note is that right now tab-modal sheets are only used for website authentication. The other sheets we use (for file selection, etc) are currently window-modal; we hope to convert them over soon.

The fate of tab modal sheets, however, isn't certain. A way to enforce tab-modal interaction is certainly needed. But is attaching sheets to the tabs the right way to achieve that goal? At the last WWDC, I talked to some graphic designers who were opposed to the idea. "Reusing sheets in a context that isn't window modality will only confuse the user!" On the other hand, my position is that the concept of modality is the same, and the context is similar enough that users will find that sheets help them understand the modality in which they must interact.

So the story isn't over. Tab-modal sheets are our contribution to the ongoing discussion, an experiment to see what works and what doesn't. Together we can work out the best way to help users interact with their computers.

Posted by Avi Drissman, Software Engineer