The problem of CSS history sniffing finally got so bad and became so
high profile that approximately 10
years after it first came up, all the major browser vendors finally broke the
functionality required for the attack.
Many Web developers who relied on
the underlying functionality were vocally upset, but apparently this was an
acceptable level of breakage from the
browser vendors’ perspective.
When the breakage is not acceptable, but the issue is still bad, new
opt-in browser security features are
put forth. They generally have low
adoption rates. Prime examples are
Content Security Policy, X-Frame-Options, Origin, Strict Transport Security, SSL (Secure Sockets Layer),
Secure and HttpOnly cookie flags, and
others. Website owners can implement these solutions only when or if
they want to, thereby managing their
own breakage. What none of these
features do is to allow Web users to
protect themselves, something every
browser should enable its users to do.
Right now, Web security is in a holding pattern—waiting for the bad guys
to cause enough damage—which then
should give enough juice to those with
the power to take action.
Beyond the status Quo
The path toward a more secure Web
has a few options. We could establish a
brand-new World Wide Web, or an area
within it. A Web platform designed to
be resilient to the current laundry list of
problems, however, will forever plague
its predecessor. For the moment, let’s
assume we technically know how to
make a secure platform, which is a big if.
The next step would be to convince
the developers behind the millions,
potentially hundreds of millions, of
important websites to move over and/
or build atop version two. Of course,
the promise of a “more secure” platform would not be sufficient incentive by itself. They would have to be
offered something more attractive
in addition. Even if there were something more attractive, this path would
only exchange our backward-compat-ibility problem for a legacy problem,
which is likely to take years, perhaps a
decade or more, to get beyond.
There is another path—one that
already has a demonstrated model of
success in mobile applications. What
you find there basically amounts to
many tiny Web browsers connected
to the mobile version of the main
website. The security benefit pro-
vided by mobile platforms such as
Apple’s iOS and Google’s Android
is that the applications are isolated
from one another in both memory
and session state.
Related articles
on queue.acm.org
Browser Security
Charles Reis, Adam Barth, and Carlos Pizano
http://queue.acm.org/detail.cfm?id=1556050
Security in the Browser
Thomas Wadlow and Vlad Gorelik
http://queue.acm.org/detail.cfm?id=1516164
Cybercrime 2.0: When the Cloud Turns Dark
Niels Provos, Moheeb Abu Rajab,
and Panayiotis Mavrommatis
http://queue.acm.org/detail.cfm?id=1517412
Jeremiah Grossman is the founder and CtO of
WhiteHat security, where he is responsible for Web
security R&d and industry outreach. He is a cofounder of
Web application security Consortium (WasC) and was
previously named one of Info World’s top 25 CtOs. He
serves on the advisory boards of two start-ups, Risk I/O
and sd Elements. before founding WhiteHat, he was an
information security officer at yahoo!
© 2013 aCM 0001-0782/13/01
