When the Google Chrome Security Team isn’t busy giving prompt attention to finding and fixing bugs, we’re always looking for new security features to add and hardening tweaks to apply. There are some changes worth highlighting in our current and near-future Chromium versions:

Chromium 11: strong random numbers for the web
We added a new Javascript API for getting access to a good source of system entropy from a web page. The new API is window.crypto.getRandomValues. Web pages should not currently be using Math.random for anything sensitive. Instead of making a round-trip to the server to generate strong random numbers, web sites can now generate strong random numbers entirely on the client.

Chromium 12: user-specified HSTS preloads and certificate pins
Advanced users can enable stronger security for some web sites by visiting the network internals page: chrome://net-internals/#hsts


You can now force HTTPS for any domain you want, and even “pin” that domain so that only a more trusted subset of CAs are permitted to identify that domain.

It’s an exciting feature but we’d like to warn that it’s easy to break things! We recommend that only experts experiment with net internals settings.

Chromium 13: blocking HTTP auth for subresource loads
There’s an unfortunate conflict between a browser’s HTTP basic auth dialog, the location bar, and the loading of subresources (such as attacker-provided <img> tag references). It’s possible for a basic auth dialog to pop up for a different origin from the origin shown in the URL bar. Although the basic auth dialog identifies its origin, the user might reasonably look to the URL bar for trust guidance.

To resolve this, we’ve blocked HTTP basic auth for subresource loads where the resource origin is different to the top-level URL bar origin. We also added the command line flag switch --allow-cross-origin-auth-prompt in case anyone has legacy applications which require the old behavior.

Chromium 13: Content-Security-Policy support
We added an initial implementation of Content Security Policy, which was first introduced in Firefox 4. You can use the X-WebKit-CSP header to experiment with our implementation. We’re working with Mozilla and others through the W3C to finish the standard. Once that’s done, we’ll remove support for the X-WebKit-CSP header and add support for the final header name. Please feel encouraged to kick the tires and let us know how we can improve this feature!

Chromium 13: built-in certificate pinning and HSTS
We’re experimenting with ways to improve the security of HTTPS. One of the sites we’re collaborating with to try new security measures is Gmail.

As of Chromium 13, all connections to Gmail will be over HTTPS. This includes the initial navigation even if the user types “gmail.com” or “mail.google.com” into the URL bar without an https:// prefix, which defends against sslstrip-type attacks.

The same HSTS technology also prevents users from clicking through SSL warnings for things such as a self-signed certificate. These attacks have been seen in the wild, and users have been known to fall for such attacks. Now there’s a mechanism to prevent them from doing so on sensitive domains.

In addition in Chromium 13, only a very small subset of CAs have the authority to vouch for Gmail (and the Google Accounts login page). This can protect against recent incidents where a CA has its authority abused, and generally protects against the proliferation of signing authority.

Chromium 13: defenses for self-XSS via javascript URLs
Working together with Facebook and other browser vendors, we’re trialing a self-XSS defense that makes it harder for users to shoot themselves in the foot when they are tricked into pasting javascript: URLs into the omnibox.

This is an interesting area because it’s hard to know what detail of instruction it is possible to trick a user into following. It is also hard to measure success until a large percentage of installed browsers have the defense (thus forcing the attackers to adapt their approach).

Still hiring!
We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents for both Chrome and ChromeOS. We can promise exciting and varied work, working to protect hundreds of millions of users and working alongside the best in the industry. Why not have a look at our job posting?

Posted by Chris Evans of the Google Chrome Security Team. With thanks to Adam Barth, Adam Langley, Cris Neckar and Tom Sepez for implementing the above features.