15 secrets of next-gen browsers

The browser market is heating up, with the major players poised to release new versions this spring, and Google having entered the mix with its newly released Chrome browser. We analyzed beta code for Internet Explorer 8.0, Firefox 3.1, Opera 10, Safari 4, and looked at Google Chrome, and found many obvious changes - improved tabbing systems, better performance, privacy helpers, integration with Web applications, polished interface, and much more.

But there are underlying changes in the areas of security, networking and development that IT professionals who support users on their networks or run sites that must accommodate users wielding these browsers need to understand.

View slideshow

Part I: Security

The dramatic rise of phishing, malware and cross-site scripting (XSS) attacks has forced browser vendors to revisit security in their offerings. The most recent generations of browsers contain a number of subtle changes to improve browser security. Internet Explorer 8 in particular includes several important changes, but developers and administrators have to know they exist before they can take advantage them.

1. IE8 takes on cross-site scripting

Internet Explorer 8 tries to help stem the rising tide of XSS attacks by addressing what is dubbed a Type 1 or non-persistent XSS attack. To that end, Microsoft has added a filter to Internet Explorer 8 that looks at URLs for common patterns like "<script>" found in the URL and then knocks it down, often by simply substituting a character. If such values should be legitimately found in a URL, it is possible to disable the feature by returning the HTTP header X-XSS-Protection with a value of 0 either at the server or application level.

There are also small developer focused XSS preventative measures in IE8 which apply to the new JavaScript toStaticHTML() method that can be used to purify received content that may include malicious script code in it. Making sure that site developers sanitize received content is a best practice that should be encouraged.

If a Web site links to another site's JavaScript or consume received HTML or JavaScript payloads with little inspection, administrators and developers alike must realize that they are only as safe as what is linked to. Given the dynamic nature of JavaScript there is simply little end to the kind of mischief that can be achieved. Indeed the dark side of Web 2.0 is a naïve blind trust of end users and Web services on public facing sites, so while these browser changes may help address XSS in some ways, ultimately, they cannot solve the underlying problem of not acknowledging the security relationship implicitly in play.

2. Combating Clickjacking

To combat clickjacking – the process of getting users to think they are clicking on one thing when they are really clicking on another object hidden in some inline frame -- Internet Explorer 8 now supports a new HTTP header X-FRAME-OPTIONS, which instructs the browser the means by which it should handle how the current URL should be framed. For example, a value DENY for this header prevents content from being included in a frame, while a value of SAMEORIGIN forces a rule that states that the URL of any framed content must share the same domain as the hosting page.

Setting the X-FRAME-OPTIONS header globally at the Web server level would reduce the likelihood of clickjacking efforts being successful. But that solution assumes the protected end user is working in an upgraded Internet Explorer 8 browser as the feature is currently unique to it.

Another way to help with clickjacking would be to put a frame-busting JavaScript in place within pages that might be clickjacking targets. While this may assist in mitigating the technique in some situations, it won't cover all. It should be noted that JavaScript-based fixes can be overridden by a sophisticated attacker. The advantage, though, of this lesser scheme doesn't require Internet Explorer 8 as the browser.

Getting the user to install a special (read, little-known) plug-in like Noscript for Firefox results in the best clickjacking protection, but such a solution is unlikely to be used broadly and will have potentially consequences in limiting JavaScript use even when it is employed properly.

3. Cross-site request forgery - Old solutions still rule

Making sure that a request coming in to a Web server is coming from a previously delivered page is one way to reduce clickjacking and cross site request forgery attacks. Checking the HTTP Referer header is the traditional way to do this, and can be accomplished using server filters and application changes.

Interestingly, using the Referer header does offer quite a reasonable solution, but the fact that it is often dumped for privacy reasons has slowed interest in applying this defense.

The technique, though, is actually fundamentally sound, so a new Origin header is now emerging in the next generation browsers that provides similar functionality, but with less privacy concerns. To reduce CSRF attacks, setting and monitoring what sites and services can link to their sites is an important task for site administrators and application developers should address together.

4. MIME Smuggling: An ON/OFF Switch in IE 8

One annoying aspect of both the existing and upcoming versions of Internet Explorer is that far too often when Microsoft makes things easier for developers, it also consistently opens up troubling security problems for end users and site owners alike. (See slideshow image.)

A prime example is the MIME-sniffing process, where Internet Explorer looks inside of received responses and attempts to address the content appropriately with regards to what it sees in the body of the response, rather than as how it is actually labeled in the Content-Type header.

The problem here is that while this process may let developers and administrators off the hook in having to understand what MIME types and the Content-Type header are used for or configure them in applications or on servers, the result is a window for unscrupulous folks on the Internet to be able to smuggle content past any security or network filters that don't perform deep packet inspection because they only look at header or file extension. When MIME smuggling is possible, XSS attacks also become possible in unexpected situations such as when there is a response, which is stamped as an image, but actually contains a malicious script that then gets executed.

Now, with IE8 Web site managers and application developers can turn off MIME sniffing by sending the X-Content-Type-Options: nosniff in responses, which should be set by Web administrators globally in Web server responses.

5. HTTP-only cookies

When XSS attacks are successful, they very commonly attempt to echo or manipulate cookies for session hijacking or account login purposes. Firefox 2/3+ and IE 6 SP1+ support a cookie extension that makes it illegal for JavaScript to read the cookie if it is flagged with an "HTTPOnly" tag. (See slideshow image.)

Setting the HTTPOnly tag in a cookie thwarts a rogue JavaScript that would typically be inserted in an XSS attack from reading or changing a cookie, and, therefore knocks down many session hijacking problems.

This isn't the newest technology, as it has been supported since later service patches of IE6, but the newer releases of browsers are widely supporting the idea, and, finally, cleaning up small details. That makes it high time for this relatively rarely used feature to be more widely deployed. Fortunately, the change generally can be configured globally in application server settings and is particularly important for session cookies.

6. Cross Domain Access: Pandora's box?

Traditionally AJAX applications have not being able to break the same origin security policy. Here, a page served from a fully qualified domain name like www.networkworld.com can't call a URL on another domain. The restriction is specific to the point of denying a domain that does not exactly match the string. So, for example, networkworld.com by itself would be off limits for cross-domain access. Such restrictions are quite purposeful, and are there for our safety, especially considering the dynamic nature of JavaScript.

Wily Web developers, though, want to build client-side mash-ups and perform client-side Web service calls using various workarounds that range from <iframe>, and Flash to <script> tag-based communication that at least partially circumvent this restriction.

In both Firefox 3.1 and IE8, browser vendors bend toward the desire for neat cross-domain tricks and loosen the same origin policy by implementing the W3C specification for cross-site access control. Posts within the WebKit community show that official support for this in Safari and Chrome is also upcoming. In Microsoft's case, the XDomainRequest (XDR) object is used to make a cross-domain request. Firefox simply uses the XMLHttpRequest itself.

In either case, sites receiving cross-origin requests can return the Access-Control-Allow-Origin HTTP header to inform requesting URLs whether they are allowed to make a cross origin call or not. The mechanism is somewhat similar to what Flash has supported with the crossdomain.xml file. Unfortunately, like with Flash, we will likely see a lot of wildcard values used for cross-origin requests regardless of implementation, which provides little of the intended value of such technology.

Developers and server administrators must get together and define a cross-origin policy for their sites if they expose services. Also, outbound cross-origin requests must be understood both by network and application development teams if application security is to stand any chance of being maintained.

Part II: Networking

While not as abundant as security changes, there are an interesting set of features being rolled into Web browsers to improve performance. Google's Chrome contains new compression and request reduction features. It is quite likely similar changes are going to be implemented widely as Web applications in need of speed take advantage of such features.

View slideshow

7. Two connection limit broken

Traditionally HTTP 1.1 compliant browsers will limit persistent connections to two per domain. IE8 and Firefox 3+ have upped this limit to six when broadband is used. In non-persistent connections, the values are potentially even much higher. The other browsers also have mostly removed the connection limit and thus the two connection limit will become a moot point.

These browser request limit changes will have the effect of potentially increasing simultaneous request load on servers so site administrators should be more aware of what their server capacity is, as it may take fewer users to reach such limits.

8. Precaching DNS Lookups and more

View slideshow

With many sites using multiple scripts from other domains for analytics, widgets and wide variety of Web services, a single page may include many more DNS look-ups than ever before. Given the variable resolution time of domains, such lookups can really slow a page rendering down. Both Chrome and FireFox 3.1 have DNS pre-resolution features built into them.

Prefetching to improve performance is not a new idea in the browser realm. Firefox has long supported the ability to pre-fetch content with an HTML tag like <link rel="prefetch" href="fatimage.jpeg"> or an HTTP header like Link: <fatimage.jpeg>; rel=prefetch. Regardless of scheme, though, pre-fetching does have the downside of potentially performing network actions that may not be needed.

Network administrators might see DNS query increases as these browsers become more popular. The use of content prefetching techniques should be discussed with application developers to ensure that they are used purposefully to improve end user performance or are limited in order to preserve server and network capacity.

9. Protocol changes on the horizon

Chrome has introduced a number of new low-level features that have seemed to fly under the radar, but certainly need some attention from IT organizations. First, Google implemented the bzip2 protocol for transparent HTTP compression, which has significant potential savings for large text payloads over the commonly employed gzip algorithm. (See image in a slideshow.)

Chrome has also silently introduced the Shared Dictionary Compression over HTTP (SDCH), which is, coincidentally, also found in the Google toolbar. This protocol allows for a common dictionary file to be sent and pages automatically built from pieces of the dictionary that contain differences in content. Given that Web documents often share the same HTML document template, CSS and JavaScript information, a differencing-focused protocol such as SDCH could significantly reduce the amount of repetitive content sent as subsequent pages are delivered.

Click to see: Chart comparing performance of grip vs bzip

Network administrators should explore newer compression and request optimization schemes to improve site access speed for end users and provide more scalability without further hardware and network investment.

10. Off the network

One of the major changes introduced in recent browsers is the support for offline access. Storing data is the first step in going offline. Most of the modern browsers including IE8, Firefox 2+ and Safari implement the DOM storage mechanism to save a fairly large amount of data locally. Safari even supports HTML 5 database style storage locally, which is likely coming to other HTML 5 focused browsers soon.

Firefox, with improvements included in Version 3.1 also supports an application cache. Both IE 8 and Firefox support the JavaScript property navigator.onLine to detect the connection state of the browser, demonstrating the fact that soon browsers will not have to rely on add-ons such as Google Gears to work when disconnected.

For now there is little for the administrator to do in light of the technology changes, but these ideas foreshadow that in the not too far off future the line between Web and standard applications will blur to the point that any application deployment and management practices in play will have to apply to both.

Part III: Development gains

Web developers in particular have been quite excited about the resurgence of browser innovations. The biggest change -- IE 8's embracing of standards -- will be the most important improvement that may require some pre-emption lest the browser's final release cause Web site owners headaches.

View slideshow

11.) Internet Explorer 8 - Standards mode shockwaves

Web developers have long maligned the Internet Explorer browser family for not properly supporting HTML and CSS standards. Workarounds and hacks are commonly required to make IE 6 and even IE 7 render some layouts properly. With the introduction of IE 8 much of these hacks will no longer be needed, but unfortunately, when the newer browser encounters the old "fixes", page layouts may break. Microsoft does provide the user with a special compatibility mode button to press in case a site doesn't render correctly. (See slideshow image.)

However, rather than force users to fix your site, it is better to add in a patch until the pages can be modified. An HTML tag like <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"> or the equivalent HTTP header delivered X-UA-Compatible: IE=EmulateIE7 site wide will flip Explorer into another mode in case a site can't be changed soon enough.

Web server administrators are well advised to consider looking right away at adding such a response header globally. Unless the Web team has made fixes to a site's HTML and CSS, an emergency request for this quick fix may be in order when IE 8 is in widespread use.

12. CSS 3 preview

While Microsoft was busy addressing older CSS1 and 2 specifications, the other browser vendors were quickly implementing various CSS3 features including rounded corners, border images, multiple columns, drop shadows, downloadable fonts and more. (See slideshow image.)

A richer palette is on the way, and because of the use of prefixing of rules -- like -webkit and -moz on these newer CSS properties -- many of the features can be layered into documents now for those with the latest technologies without affecting users hitting the same pages with older browsers.

Not much impact here for the administrator other than -- like other users -- to enjoy a continued improvement in Web experience with newer browsers.

13. JavaScript - The need for speed

Much has been made of the JavaScript performance gains in new browsers. All, save IE 8, are sporting new JavaScript engines with fun names like V8 in Chrome, Squirrelfish in Safari, Tracemonkey in Firefox 3.1 and Carakan in Opera 10.

Statements from Microsoft suggest that after IE 8 launches, improvements on that front are likely to be forthcoming as well. We've looked at performance previously, but depending on the benchmark and the latest build, the standings inevitably change rapidly. Until the dust starts to settle, we'll simply state JavaScript is getting faster in every browser.

Interestingly network administrators may enjoy some unearned kudos with new browsers implementing faster JavaScript as their users wonder what made things run faster. (See benchmarks for WebKit's Sunspider and Mozilla's Dromaeo.

14. JavaScript - New features of note

Part of the motivation for running code faster is that browsers will interrupt long running scripts in order to mitigate possible browser lockup. While such a safety net can be useful given how important JavaScript is becoming, limiting what you can do with it isn't the best idea. Firefox 3.1 introduces the concept of Web workers, which allow JavaScript developers to run some JavaScript tasks in the background. Previously, if developers have wanted to accomplish this, they would have to pull nasty tricks or tap into Google Gears.

Lesser discussed, but still important, changes have been introduced to JavaScript at the feature level. Emerging support for the W3C Selectors API allows JavaScript applications to use CSS selectors to select DOM elements using a method such as document.querySelectorAll(). Native support for such DOM features will make many JavaScript libraries such as jQuery much faster. Likewise, native JSON encode and decode support is found in both IE 8 and Firefox 3.1, which not only improves performance of some AJAX applications that rely on such transformations, but may improve security somewhat as well.

Similar to the massive CSS changes, JavaScript speed and feature improvements will likely just make Web applications more enjoyable for all as we continue to march to a Web focused application environment.

15. HTML 5 features today?

Some might characterize HTML 5 as a kitchen sink specification. It addresses the future of markup in a world barely interested in writing valid markup now, let alone XML-focused markup like XHTML, alongside Web application ideas ranging from offline usage, push communication and drawing.

Yet, out of this wild specification, useful features are landing much faster than most are aware. Already Safari 3 and 4 and Firefox 3.1 support multimedia with HTML 5's <audio> and <video> tags. The least HTML 5-aware browser, IE 8, does support some things like DOM Storage and appears to happily coexist with emerging HTML 5 elements with simple fixes applied.

Newer HTML 5 features introduce more browser complexity than ever before and lead to a clear "fat client" approach to applications. Network administrators should be well aware which of the emerging features employed by Web applications they need to support as speed and security concerns could be undesirable side-effects of their introduction.

Enjoying the spoils of the browser wars

While there is disruptive change ahead to contend with, the spoils of the continuing browser wars go to us - the Web developers and site administrators. Slicker tabs and "awesome" URL bars might be nice for the end user, but seeing browser vendors finally get around to fixing and improving browser security, network considerations and development infrastructure is sure to pay more dividends in the future.

Powell is a member of the Network World Test Alliance and is an author of numerous Web development books. He can be reached at tpowell@pint.com.