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

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 Handbook⁶ 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