Highlights of New Chromium Security Features: June 2011

Google's Chromium team today highlighted some upcoming changes in the current and near-future Chromium versions. Here's the list:Chromium 11: strong random numbers for the webA new Javascript API window.crypto.getRandomValues added for getting access to a good source of system entropy from a web page. Web pages shouldn't currently be using Math.random for anything sensitive. Instead […]

Google's Chromium team today highlighted some upcoming changes in the current and near-future Chromium versions. Here's the list:

  • Chromium 11: strong random numbers for the web
    A new Javascript API window.crypto.getRandomValues added for getting access to a good source of system entropy from a web page. Web pages shouldn't 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, Google blocked HTTP basic auth for subresource loads where the resource origin is different to the top-level URL bar origin. Also added the command line flag switch --allow-cross-origin-auth-prompt in case anyone has legacy apps which require the old behavior.

  • Chromium 13: Content-Security-Policy support
    Added an initial implementation of Content Security Policy, first introduced in Firefox 4. You can now use X-WebKit-CSP header to experiment with our implementation.
  • Chromium 13: built-in certificate pinning and HSTS
    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
    Together with Facebook and other browser vendors, Google's trialing a self-XSS defense that makes it harder for users to shoot themselves in the foot when they're tricked into pasting javascript: URLs into the omnibox.

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

[Source: Chromium blog]