5 Security Enhancements in Chrome

Posted by Abel Avram on Feb 04, 2010

Sections

Development,

Architecture & Design

Topics

Architecture ,

Security

Tags

IE8 ,

Firefox ,

Safari ,

Chrome ,

Browsers

Google has added five security enhancements to Chrome in order to make browsing more secure: cross-documents message posting, Strict Transport Security, Origin and X-Frame-Options header fields, and Reflective XSS Filter. Some of these features have already been or are to be implemented by other browsers.

Posting Messages

Browsers forbid documents belonging to different domains to communicate with each other for security and privacy reasons. HTML 5 introduces a new method called postMessage(), a method allowing documents in separate iFrames to communicate with each other. The method’s signature is:

window.postMessage(message, [ports,] targetOrigin)

That way browsers can retain the security provided by iFrames but can also provide cross-document communication.

Strict Transport Security

HTTPS is a secure way to connect to a web site and transfer sensitive information that needs to be protected. But HTTPS is not enforced all the way by browsers. For example, if there is a problem with a security certificate issued by a web site, the browser generates a warning on that but the user can go on with a half-secure connection. PayPal has lobbied for the introduction of an HTTP header field called Strict-Transport-Security (STS) into the HTML 5 specification. When the server returns an HTTP header containing STS, the browser implementing this feature should do the following:

1. The UA [User Agent] terminates, without user recourse, any secure transport connection attempts upon any and all secure transport errors or warnings, including those caused by a site wielding self-signed certificates.

2. UAs [User Agent]  transform insecure URI references to a STS Server into secure URI references before dereferencing them.

This feature forces using HTTPS when either the web server or the user agent consider that as necessary. Using a non secure HTTP connection over a wireless connection in a crowded place opens up the door to eavesdropping resulting in possible disclosure of one’s accessing credentials to a web site. STS would protect against that.

Currently PayPal implements the feature. Chrome 4 also implements STS, and NoScript, a security add-on for Firefox, can be used with the same purpose. A native implementation of STS in Firefox is under way.

Origin

Cross-site request forgery (CSRF) attacks are a known way of tricking a web site into unwittingly providing confidential information to another web site. Origin, a new HTTP header field proposed to be included in HTML 5, attempts to solve that problem by having the user agents specifying the origin of a request. When a malicious web server redirects a request toward another web server, the browser will include the origin of the redirect in the request. The destination web server will decide if the Origin can be trusted or not serving the request accordingly.

Both Google and Mozilla are working one implementing the feature in their respective browsers. The W3C specification provides more details.

X-Frame-Options

Another HTTP header field, X-Frame-Options can be used to defend against ClickJacking attacks. Such an attack is orchestrated by overlaying an invisible frame on top of another and while the user thinks he clicks on controls of a web page, he actually enters input in another. Web sites can protect themselves against ClickJacking by specifying “X-Frame-Option: deny” and supporting browsers will refuse to render the page in frames thus preventing a ClickJacking attack.

IE 8 was the first to implement this feature followed by Chrome and Safari.

Reflective XSS Filter

Cross-site scripting (XSS) is yet another method of exploiting security vulnerabilities, and one of the most difficult to deal with. IE 8 and Firefox’ NoScript  add-on have a reflective XSS filter, feature that has been added by Google to WebKit and used by Chrome 4. The filter verifies if “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.”

• Older >