To mitigate last year’s Spectre vulnerabilities, Chrome introduced Site Isolation. Version 77 last month saw the Android browser gain similar protections as the desktop counterpart, with Google today detailing the security measure and future plans.
Site Isolation renders pages in separate processes to prevent malicious sites from stealing passwords, cookies, and additional data from open browser tabs. On Android, Google has to factor in how phones are constrained by CPU, memory, and battery.
As such, a “slimmer form of Site Isolation” on mobile only protects high-value pages where users sign in with a password. Banking, shopping, and other sensitive data is “rendered in its own dedicated renderer process, walled off from other sites,” while less critical sites can share processes.
Chrome has a list of mobile sites where credentials are most frequently entered. Pages not covered by this crowdsourced directory are added after the browser observes a password interaction.
Navigations to other sites will cause a tab to switch processes, and cross-site iframes are put into a different process, becoming “out-of-process iframes.” Chrome keeps a list of isolated sites stored locally on the device and clears the list whenever users clear their browsing history or other site data.
According to Google, Site Isolation is a “behind-the-scenes architectural change that should not change the experience for users or developers.” But there is a performance impact to the tune of “3%-5% total memory overhead in real workload.”
This password-based Site Isolation is enabled for 99% of users today on Android devices that have over 2 GB of RAM. Chrome does let you enable “chrome://flags/#enable-site-per-process” to have all browsing be protected, though there are performance warnings. Google detailed upcoming mobile measures, like letting websites opt in to Site Isolation and further optimizations.
Meanwhile, Chrome 77 now protects against “significantly stronger attacks” on desktops:
Our initial launch targeted Spectre-like attacks, which could leak any data from a given renderer process. Site Isolation can now handle even severe attacks where the renderer process is fully compromised via a security bug, such as memory corruption bugs or Universal Cross-Site Scripting (UXSS) logic errors.
Current measures today include:
- Authentication: Cookies and stored passwords can only be accessed by processes locked to the corresponding site.
- Network data: Site Isolation uses Cross-Origin Read Blocking to filter sensitive resource types (e.g., HTML, XML, JSON, PDF) from a process, even if that process tries to lie to Chrome’s network stack about its origin. Resources labeled with a Cross-Origin-Resource-Policy header are also protected.
- Stored data and permissions: Renderer processes can only access stored data (e.g., localStorage) or permissions (e.g., microphone) based on the process’s site lock.
- Cross-origin messaging: Chrome’s browser process can verify the source origin of postMessage and BroadcastChannel messages, preventing the renderer process from lying about who sent the message.
Author: Abner Li
Source: 9TO5Google
