Security
IN THE BROWSER
THE USE MODEL IS EVOLVING…

Key features of early browsers included encryption and cookies, which were fine for the simple uses of the day. These techniques enabled the start of e-commerce, and monetizing the Web was what led to many security problems. Attackers who want money go where the money is, and there is money to be had on the Web.

Today users expect far more from a browser. It should be able to handle sophisticated banking and shopping systems; display a wide variety of media, including video, audio, and animation; interact with the network on a micro scale (such as what happens when you move the cursor over a DVD selection in Netflix and see a summary of the movie); and update in as close to realtime as possible—all without divulging sensitive information to bad guys or opening the door for attackers.

Consider AJAX (Asynchronous JavaScript and XML). A Web page can contain code that establishes a network connection back to a server and conducts a conversation with that server that might bypass any number of security mechanisms integrated into the browser. The growing popularity of AJAX as a user-interface technique means that an enterprise network often allows these connections so that popular sites can function correctly.

The underlying mechanism of AJAX (which, despite the name, may not necessarily use JavaScript, XML, or be asynchronous) is a function called XMLHttpRequest, ⁵ originally introduced by Microsoft for Internet Explorer, but now supported by Firefox, Safari, Opera and others. XMLHttpRequest allows a part of a Web page to make what is effectively a remote procedure call to a server across the Internet and use the results of that call in the context of the Web page. It is a powerful tool, but one that is open to a number of attacks.¹

Flash, JavaScript, and Java all allow programs written by unknown third parties to run within the browser. Yes, there are sandboxes and safeguards, but as any attacker will tell you, a big step toward penetration is getting the target machine to run your code.

…AND SO IS THE THREAT MODEL

Early browsers had several major and noteworthy vulnerabilities, but they also had fewer types of attackers. The early attackers tended to be motivated by curiosity or scoring points with their peer groups. Modern browsers must defend against increasingly well-organized criminals who are looking for ways to turn browser vulnerabilities into money. They are aggressive, methodical, and willing to try a variety of attacks to see what works. Then there are those who work in gray areas, not quite violating the law but pushing the envelope as hard as possible to make a few bucks.

With more aggressive threats come more aggressive defenders. Security experts wanting to make names for themselves can release vulnerability information about browsers faster than browser developers may be prepared to react. While the roots of this type of disclosure are often driven by noble motives, the results can be devastating if they are not handled properly by all parties.

The flip side of early disclosure is the zero-day exploit. In this type of attack, an attacker learns of a flaw in a browser and moves to exploit it and profit from it before the security community has an opportunity to mount a defense.

Injection attacks (sometimes known as XSS, or cross-site scripting) are when an attacker embeds commands or code in an otherwise legitimate Web request. This might include embedded SQL commands; stack-smashing attempts, in which data is crafted to exploit a programming vulnerability in the command interpreter; and HTML injection, in which a post by a user (such as a comment in a blog) contains code intended to be executed by a viewer of that post.

XSRF (cross-site reference forgery) is similar to XSS, but it basically steals your cookie from another tab within your browser. This is relatively new, since tabbed browsing has become popular in only the past few years. It’s an interesting demonstration of how a browser feature sometimes amplifies old problems. One of the reasons Google engineers implemented each tab in a separate process in Chrome was to avoid XSRF attacks.

A similarly named but different attack is cross-site request forgery, in which, for example, the victim loads an HTML page that references an image whose src has been replaced by a call to another Web site, perhaps one where the victim has an account. Variations of this attack include such things as mapping networks within the victim’s enterprise for later use by another attack.