Chrome has introduced
Site Isolation to make it harder for malicious web pages to steal data from the user's other web accounts, even if an attacker uses a Chrome security bug to compromise a renderer process. This greatly improves security for Chrome users, but it is possible for security issues in extensions to erode some of this protection.
This email provides guidance for how extension authors can help prevent extension security bugs that malicious web pages might use to bypass Site Isolation protections.
The most important advice is to
treat content scripts as less trustworthy and possibly under the control of the page they're modifying. A malicious web page can influence the behavior of a content script, use a side channel attack like
Spectre to leak data from the content script, or compromise Chrome's renderer process to gain full control over the content script.
More specifically, please audit your extension to ensure you follow these security best practices:
- Protect against cross-site scripting when receiving messages from content scripts.
- Avoid sending sensitive data to a content script if it should not leak to the web page. Secrets from the extension, data from other web origins, browsing history, and other sensitive data might be accessible to the web page if sent to the content script.
- Limit the scope of privileged actions that can be triggered by content scripts. Do not allow messages from content scripts to result in fetching arbitrary URLs or passing arbitrary arguments to extension APIs (e.g., chrome.tabs.create).
- Validate and sanitize all messages and input from a content script.
For more security best practices see
Stay Secure in the Chrome Extensions documentation. More details are outlined below, and please send any questions to
site-isol...@chromium.org. Thank you for keeping Chrome users secure!
Best regards,
Lukasz Anforowicz, on behalf of the Site Isolation Team
Why now? What has changed?
Site Isolation offers stronger defenses against cross-site attacks. Side channel attacks like Spectre can read any data from an attacker page's renderer process, so Site Isolation avoids putting data from other websites into the renderer process. Also, attackers who find a security bug in Chrome's renderer process may be able to compromise the process, allowing them to run arbitrary code or send spoofed messages to other Chrome processes. Site Isolation makes it harder for such processes to attack other websites.
These changes to Chrome make it more difficult for malicious web pages to attack other websites. Based on bug reports we have received, we think that attackers may consider extensions as another attack vector and as a potentially easier way to attack other websites. This is why we are proactively reaching out and highlighting the importance of extension security.
What is a compromised renderer process?
Attackers may find security bugs in Chrome's renderer process, such as in the JavaScript engine, DOM, or image parsing logic. Sometimes, these bugs may involve memory errors (e.g., a "use-after-free" bug) which allow an attacker's web page to execute their own, arbitrary, native code (e.g. assembly/C++ code, as opposed to Javascript code) in the renderer process. We call such a process a “compromised renderer.”
A compromised renderer is no longer constrained by the rules of JavaScript or the Same Origin Policy. Instead, it can access any data in the process or send forged messages to Chrome's browser process or extension processes, such as pretending to be an extension's content script.
The Chrome sandbox limits what damage a compromised renderer can do. A compromised renderer has full access to any website hosted in it, but with Site Isolation the renderer can only host one website. Thus, it is harder for an attacker's page to access other websites. Nevertheless, a compromised renderer can try to trick extensions into attacking other websites, for example by spoofing messages from a content script to the extension background page.
Why are content scripts at greater risk than background pages?
A content script runs in the same process as the web page it is modifying. If that web page is malicious, it can compromise the renderer process and impersonate a content script. It is easy for an attacker to embed a malicious script or image in their own website in an effort to compromise the renderer process hosting the website.
Why should I protect my extension against compromised renderers?
The Chrome team does prioritize fixes for security bugs in Chrome's renderer process, so it may seem unnecessary for extensions to worry about them as well. However, such security bugs are
common enough in practice that it is important to limit the damage they can cause.
Protection against compromised renderers is why Chrome's architecture uses features like the sandbox and Site Isolation. To escape the renderer sandbox or bypass Site Isolation, an attacker needs to find yet another bug; such bugs in Chrome
are treated as high-severity security bugs. Similar security bugs in extensions should also be treated as high severity by extension authors.
In addition, note that some of the attacks described here do not depend on bugs in Chrome. For example, even without compromising a renderer, an attacker's web page can use side channel attacks like Spectre (which may leak data from the content script or elsewhere in the process) or a
named items attack (to control variables across isolated worlds).
What is Chrome doing to help me secure my extensions?
We are continuously working to make Chrome more secure through a variety of architectural efforts, security bug fixes, sandbox improvements, and other changes. It's also important that we provide extension developers the right tools and APIs to secure their extensions. Please let us know if you have any suggestions for ways to help you secure your extensions.
Some recent examples of Chrome security features we are considering thanks to community feedback are:
Trusted Types support
for extensions and
a MessageSender.origin property. Hopefully these examples illustrate what kind of security features we currently think might be beneficial for securing extensions against compromised content scripts. Let us know if these ideas would be useful or if you have any other feature ideas.