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.
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
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.1
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
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.