Open source developers especially must be very careful
about designing and implementing sandbox systems,
because their sandbox source code is available to the
attacker for study and testing. This is, of course, no surprise to the sandbox developers and one reason why open
source sandboxes tend to improve quickly.
Browser developers have come up with several ways to
combat phishing attacks as well, primarily heuristics to
detect an attempted visit to a fraudulent site, techniques
to aggregate lists of and warn about known phishing sites,
and augmentation of login security.
Injection attacks are most properly defended against at
the server, but the victim will often be the browser user,
not the server owner. Therefore, browsers may implement
policies that hamper the injection attack by limiting
where resources may be accessed from within a particular
page.
Firefox has aggressively pursued a strategy of patching
known vulnerabilities and generates updates regularly.
Internet Explorer 7 is a significant improvement over IE 6
in this regard, though many more known-but-unpatched
vulnerabilities exist in IE 7 than in Firefox. Chrome seems
to be emulating Firefox, though it lacks the mindshare of
the other two at the moment so fewer eyeballs are looking critically at it for flaws.2
Some browser developers are employing and refining
their systems for detecting, reporting, and responding to
security flaws. Mozilla.org, the support and development
organization for Firefox, enlists open source developers
to assist with code reviews and offers open bug-tracking
systems so that bugs can be reported and the follow-up
tracked.
From a defender point of view, these efforts are a
mixed blessing. Because browser software may be freely
downloaded from the Internet by any user, all browsers are suspect. Prudent defenders might hope that the
browser is sufficiently rugged, but they cannot count on
that. Desktop *nix systems and Mac OS X allow browser
software to be run at a lower permission level than Windows often does, but that safeguard may be circumvented
by other user-driven configuration changes.
CONCLUSIONS
From a network security perspective, a browser is essentially a somewhat-controlled hole in your organzation’s
firewall that leads to the heart of what it is you are trying
to protect. Although browser designers do try very hard to
limit what attackers can do from within a browser, much
of the security relies far too heavily on the browser user,
who often has other interests besides security. There are
limits to what a browser developer can compensate for,
and browser users will not always accept the constraints
of security that a browser establishes.
As this issue gets more exposure, browser developers are cooperating to some degree to share strategies
for defense. Google has published an excellent Browser
Security Handbook6 that compares various browser features
and defenses.
Attack and defense strategies are co-evolving, as are
the use and threat models. As always, anybody can break
into anything with sufficient skill, motivation, and
opportunity. The job of browser developers, network
administrators, and browser users is to modulate those
three quantities to minimize the number of successful
attacks.
And that is a very big job indeed. Q
REFERENCES
1. Stamos, A., Lackey, Z. 2006. Attacking AJAX web appli-
cations. iSEC Partners;
http://www.isecpartners.com/
files/ iSEC-Attacking_AJAX_Applications.BH2006.pdf.
2. Wikipedia. Comparison of Web browsers; http://
en.wikipedia.org/wiki/Comparison_of_web_browsers.
3. Wikipedia, HTTP cookie;
http://en.wikipedia.org/wiki/
HTTP_cookie.
4. Wikipedia. Phishing;
http://en.wikipedia.org/wiki/
Phishing.
5. Wikipedia. XMLHttpRequest; http://en.wikipedia.
org/wiki/XMLHttpRequest.
66. Zalewski, M. 2008. Browser Security Handbook. Google;
http://code.google.com/p/browsersec/wiki/Main.
LOVE IT, HATE IT? LET US KNOW
feedback@queue.acm.org
THOMAS A. WADLOW is a network and computer security
consultant, and author of The Process of Network Security
(Addison-Wesley Professional, 2000).
VLAD GORELIK is vice president of engineering at AVG
Technologies where he heads the development of behavioral
malware detection and removal technologies. Previously
he spent several years as CTO of Sana Security, leading the
company’s efforts in creating products to fight malware. He
has multiple patents and filed patent applications in software
technology and computer security.
© 2009 ACM 1542-7730/ 09/0200 $5.00
