- 18 Hot IT Certifications for 2014
- CIOs Opting for IT Contractors Over Hiring Full-Time Staff
- 12 Best Free iOS 7 Holiday Shopping Apps
- For CMOs Big Data Can Lead to Big Profits
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.
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.
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.
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.
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?
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.
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.
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
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.)
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.
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.
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.
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.
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.
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 firstname.lastname@example.org.