ware.org have tools to help publishers
remove their pages from the database
if they have been cleaned after hosting
malware. It is also possible for human
errors to flag sites incorrectly, as in an
incident in January 2009 that flagged
all URLs as dangerous.
9 Such errors
are typically fixed quickly, though, and
safeguards can be added to prevent
them from recurring.
These services also have false negatives, because not every malicious
page on the Web can be cataloged at
every point in time. Although Google
and StopBadware.org attempt to identify as many malicious pages as possible,
10 it is unlikely to be a complete
list. Still, these blacklists help protect
users from attack.
conclusion
There is no silver bullet for providing
a perfectly secure browser, but there
are several techniques that browser developers can use to help protect users.
Each of these techniques has its own
set of challenges.
In particular, browsers should minimize the danger that users face using
three techniques:
Reduce attack severity by applying ˲
the principle of least privilege in the
browser architecture. This technique
limits the damage caused when an attacker exploits a vulnerability.
Reduce the window of vulnerabil- ˲
ity by ensuring updates are developed
and deployed as quickly as possible.
This technique minimizes the number of vulnerable browsers an attacker
can target.
Reduce ho w often users are exposed ˲
to attacks by filtering out known malicious content. This technique protects
users during vulnerable time windows.
The Google Chrome team has focused on each of these factors to
help provide a secure browser while
preserving compatibility with existing Web content. To make Google
Chrome even more secure, we are investigating further improvements to
the browser’s security architecture,
such as mitigating the damage that
plug-in exploits can cause and more
thoroughly isolating different Web
sites using separate sandboxed processes. Ultimately, our goal is to raise
the bar high enough to deter attackers
from targeting the browser.
There is no silver
bullet for providing
a perfectly secure
browser, but
there are several
techniques that
browser developers
can use to help
protect users.
Related articles
on queue.acm.org
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=1483106
Phishing for Solutions
Kode Vicious
http://queue.acm.org/detail.cfm?id=1142063
References
1. barth, a., Jackson, C., reis, C., and Google Chrome
team. the security architecture of the Chromium
browser (2008); http://crypto.stanford.edu/websec/
chromium/chromium-security-architecture.pdf.
2. Douceur, J.r., elson, J., howell, J., and lorch, J.r.
leveraging legacy code to deploy desktop applications
on the Web. In Proceedings of Operating Systems
Design and Implementation (2008).
3. Duebendorfer, t., frei, s. Why silent updates boost
security. eth tech report tIk 302 (2009); http://
www.techzoom.net/silent-updates.
4. franco, r. Clarifying low-rights Ie. Ieblog (June 2005);
http://blogs.msdn.com/ie/archive/2005/06/09/427410.
aspx.
5. frei, s., Duebendorfer, t., and Plattner, b. firefox (in)
security update dynamics exposed. ACM SIGCOMM
Computer Communication Review 39, 1 (2009).
6. Google. omaha: software installer and auto-updater for
Windows. Google Code; http://code.google.com/p/omaha/.
7. Grier, C., tang, s., and king, s.t. secure Web browsing
with the oP Web browser. In Proceedings of IEEE
Symposium on Security and Privacy (2008).
8. howard, M., thomlinson, M. Windows Vista IsV
security (2007); http://msdn.microsoft.com/en-us/
library/ bb430720.aspx.
9. Mayer, M. “this site may harm your computer” on
every search result. the official Google blog (Jan.
2009); http://googleblog.blogspot.com/2009/01/this-
site-may-harm-your-computer-on.html.
10. Provos, n., Mcnamee, D., Mavrommatis, P., Wang, k.,
and Modadugu, n. the ghost in the browser: analysis
of Web-based malware. In Proceedings of the First
Usenix Workshop on Hot Topics in Botnets (april 2007).
11. reis, C. and Gribble, s.D. Isolating Web programs in
modern browser architectures. In Proceedings of
European Conference on Computer Systems (april 2009).
12. sandbox. Chromium Developer Documentation
(2008); http://dev.chromium.org/developers/design-documents/sandbox.
13. Wang, h. J., Grier, C., Moshchuk, a., king, s.t.,
Choudhury, P., and Venter, h. the Multi-Principal os
Construction of the Gazelle Web browser. Microsoft
research technical report (Msr-tr-2009-16) 2009;
http://research.microsoft.com/pubs/79655/gazelle.pdf.
14. yee, b., sehr, D., Dardyk, G., Chen, J. b., Muth, r.,
ormandy, t., okasaka, s., narul, n., and fullagar, n.
native Client: a sandbox for portable, untrusted x86
native code. In Proceedings of IEEE Symposium on
Security and Privacy (2009)
Charles Reis is a software engineer at Google working on
the Google Chrome Web browser. he recently completed
his Ph. D. in the Department of Computer science and
engineering at the university of Washington. his research
focuses on improving the reliability and security of Web
browsers and Web content.
Adam Barth is a postdoctoral fellow at the university of
California, berkeley. his research focuses on the security
of modern Web browsers, including their security policies,
enforcement mechanisms, and security user interfaces.
he is a contributor to the Chromium, Webkit, and firefox
open source projects and is an invited expert to the W3C
htMl and Web applications working groups.
Carlos Pizano is a senior software engineer at Google
working on the Google Chrome Web browser. his work
focuses on security and sandboxing for Internet-facing
applications.