auGuST 2009 | voL. 52 | no. 8 | communIcATIons of The Acm 45tHe WeB HAs become one of the primary ways people interact with their computers, connecting people with a diverse landscape of content, services, and applications. users can find new and interesting content on the Web easily, but this presents a security challenge: malicious Web site operators can attack users through their Web browsers. Browsers face the challenge of keeping their users safe while providing a rich platform for Web applications. Browsers are an appealing target for attackers because they have a large and complex trusted computing base with a wide network-visible interface. His-torically, every browser at some point has contained a bug that let a mali-cious Web site operator circumvent the browser’s security policy and compro-mise the user’s computer. Even after these vulnerabilities are patched, many users continue to run older, vulnerable versions.5 When these users visit ma-licious Web sites, they run the risk of having their computers compromised. Generally speaking, the danger posed to users comes from three fac-tors, and browser vendors can help keep their users safe by addressing each of these factors: The severity of vulnerabilities. ˲ By sandboxing their rendering engine, browsers can reduce the severity of vul-nerabilities. Sandboxes limit the dam-age that can be caused by an attacker who exploits a vulnerability in the ren-dering engine. Browser security: Lessons from Google chromeDoI:10.1145/1536616.1536634 article development led by queue.acm.orgTo shield the browser from attacks, Google Chrome developers eyed three key problems.BY chARLes ReIs, ADAm BARTh, AnD cARLos PIzAno46 communIcATIons of The Acm | auGuST 2009 | voL. 52 | no. 8practiceuser input events are exchanged via such messages. To prevent the rendering engine from interacting with the operating system directly, our Windows imple-mentation of the sandbox runs with a restricted Windows security token, a separate and invisible Windows desk-top, and a restricted Windows job object.12 These security mechanisms block access to any files, devices, and other resources on the user’s comput-er. Even if an attacker is able to exploit a vulnerability and run arbitrary code in the rendering engine, the sandbox will frustrate the attacker’s attempts to install malware on the user’s computer or to read sensitive files from the user’s hard drive. The attacker’s code could send messages to the browser kernel via the IPC channel, but we aim to keep this interface simple and restricted. Getting existing code bases such as rendering engines to work fully within this type of sandbox sometimes pres-ents engineering challenges. For exam-ple, the rendering engine typically loads font files directly from the system’s font directory, but our sandbox does not al-low such file access. Fortunately, Win-dows maintains a system-wide memory cache of loaded fonts. We can thus load any desired fonts in the browser-kernel process, outside the sandbox, and the rendering-engine process is then able to access them from the cache. There are a number of other tech-niques for sandboxing operating-system processes that we could have used in place of our current sandbox. For example, Internet Explorer 7 uses a “low rights” mode that aims to block unwanted writes to the file system.4 Other techniques include system-call interposition (as seen recently in Xax2) or binary rewriting (as seen in Native Client14). Mac OS X has an operating system-provided sandbox, and Linux processes can be sandboxed using AppArmor and other techniques. For Windows, we chose our current sand-box because it is a mature technology that aims to provide both confidential-ity and integrity for the user’s resourc-es. As we port Google Chrome to other platforms such as Mac and Linux, we expect to use a number of different sandboxing techniques but keep the same security architecture. Exploit Mitigation. Google Chrome The window of vulnerability. ˲ Brows-ers can reduce this window by improv-ing the user experience for installing browser updates, thus minimizing the number of users running old versions that lack security patches. The frequency of exposure. ˲ By warn-ing users before they visit known ma-licious sites, browsers can reduce the frequency with which users interact with malicious content. Each of these mitigations, on its own, improves security. Taken togeth-er, the benefits multiply and help keep users safe on today’s Web. In this article, we discuss how our team used these techniques to improve security in Google Chrome. We hope our firsthand experience will shed light on key security issues relevant to all browser developers. Reducing Vulnerability severity In an ideal world, all software, includ-ing browsers, would be bug-free and lack exploitable vulnerabilities. Unfor-tunately, every large piece of software contains bugs. Given this reality, we can hope to reduce the severity of vul-nerabilities by isolating a browser’s complex components and reducing their privileges. Google Chrome incorporates sever-al layers of defenses to protect the user from bugs, as shown in Figure 1. Web content itself is run within a JavaScript virtual machine, which acts as one form of a sandbox and protects differ-ent Web sites from each other. We use exploit barriers, such as address-space layout randomization, to make it more difficult to exploit vulnerabilities in the JavaScript sandbox. We then use a sandbox at the operating-system level to limit the process itself from caus-ing damage, even if exploits escape the earlier security mechanisms. Here, we discuss in more detail how these layers of defense are used. Security Architecture. Google Chrome uses a modular architecture that places the complex rendering en-gine in a low-privilege sandbox, which we discuss in depth in a separate re-port.1 Google Chrome has two major components that run in different op-erating-system processes: a high-privi-lege browser kernel and a low-privilege rendering engine. The browser kernel acts with the user’s authority and is responsible for drawing