Chromium Blog
News and developments from the open source browser project
Recent Site Isolation improvements
2019. október 17., csütörtök
In July 2018
we launched Site Isolation in Chrome
as a way to secure desktop browsers against the risk of
side-channel attacks like Spectre
. We recently published a
USENIX Security conference paper
highlighting the benefits of this launch. Today, we are pleased to announce further improvements we've rolled out in Chrome 77:
Chrome for Android has enabled Site Isolation for sites where users enter passwords.
O
n desktop platforms, Site Isolation now helps defend against attacks from fully compromised renderer processes, not just side-channel attacks.
Site Isolation on Android
Chrome 77 has brought
Site Isolation
and its benefits to Android users. Like Site Isolation on desktop, this launch leverages OS processes to make it harder for attackers to steal data from other websites. In particular, it offers the most effective
defense
against Spectre-like CPU vulnerabilities.
We wanted to ensure that Site Isolation does not adversely affect user experience in a resource-constrained environment like Android. This is why, unlike desktop platforms where we isolate
all
sites, Chrome on Android uses a slimmer form of Site Isolation, protecting fewer sites to keep overhead low. More specifically, Site Isolation is turned on only for high-value sites where users log in with a password. This protects sites with sensitive data that users likely care about, such as banks or shopping sites, while allowing process sharing among less critical sites.
Once Chrome observes a password interaction on a website, future visits to that site will be protected by Site Isolation. That means the site will be rendered in its own dedicated renderer process, walled off from other sites. 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. To bootstrap, Chrome also isolates a crowdsourced list of sites where mobile users have been entering passwords most frequently.
For the most part, Site Isolation is a behind-the-scenes architectural change that should not change the experience for users or developers. As on desktop platforms, it does cause Chrome to create more processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 3-5% total memory overhead in real workloads. We continue to work hard to optimize this behavior to keep Chrome both fast and secure.
In Chrome 77, password-triggered Site Isolation has been enabled for 99% of users (with a 1% holdback to monitor and improve performance) on Android devices that have a sufficient amount of RAM (currently 2GB). While we investigate how to bring this support to more devices, users who desire the most complete protection for their devices may manually opt in to full Site Isolation via chrome://flags/#enable-site-per-process, which will isolate all websites but carry higher memory cost.
In the future, we plan to add support for more ways of detecting when a site should be protected by Site Isolation. For example, we're working on allowing website operators to opt in any site to Site Isolation, without requiring user login.
Containing Compromised Renderers
On desktop platforms, Site Isolation in Chrome 77 now helps defend against significantly stronger attacks. 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.
For example, suppose an attacker discovered and exploited a memory corruption bug in Chrome's rendering engine, Blink. The bug might allow them to run arbitrary native code within the sandboxed renderer process, no longer constrained by the security checks in Blink. However, Chrome's browser process knows what site the renderer process is dedicated to, so it can restrict which cookies, passwords, and site data the entire process is allowed to receive. This makes it far more difficult for attackers to steal cross-site data.
In Chrome 77, Site Isolation helps protect many types of sensitive data from such compromised renderer processes:
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.
We are continuing to improve compromised renderer protections in several ways:
Bringing these protections to Chrome for Android.
This requires extra work to handle the case where only certain sites are isolated.
Protecting CSRF defenses.
Sec-Fetch-Site
and
Origin
request headers can be verified to prevent compromised renderers from forging them.
Protecting more types of data.
We are investigating how to protect additional data types by default with Cross-Origin Read Blocking.
Removing exceptions.
We are working to remove cases where these protections may not yet apply. For example, a small set of extensions still have broader cross-site access from content scripts,
until they update to the new security model
. We have already worked with extension authors to bring the affected Chrome user population down from 14% to 2%, as well as
harden other extension security issues
. Also, Site Isolation does not apply to Flash, which is currently disabled by default and is on a
deprecation path
.
We're excited about the improvements this brings to Chrome's overall security model. As a result, we are broadening the scope of the
Chrome Vulnerability Reward Program
to also cover cross-site data disclosure attacks that involve compromised renderers. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards than the usual amount for information disclosure bugs. We are grateful for the contributions from security researchers that we have received so far, and we look forward to working together further to improve the state of web security.
Posted by Alex Moshchuk and Łukasz Anforowicz, Site Isolators
Címkék
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
83
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
chrome
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
Chrome OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
cumulative layout shift
1
custom tabs
1
csrf
1
css
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
4
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
lock icon
1
long-tail
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
private prefetch proxy
1
profile guided optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
2
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2024
dec.
aug.
jún.
máj.
ápr.
márc.
febr.
2023
nov.
okt.
szept.
aug.
jún.
máj.
ápr.
febr.
2022
dec.
szept.
aug.
jún.
máj.
ápr.
márc.
febr.
jan.
2021
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2020
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2019
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2018
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2017
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2016
dec.
nov.
okt.
szept.
aug.
jún.
máj.
ápr.
márc.
febr.
jan.
2015
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2014
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2013
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2012
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2011
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2010
dec.
nov.
okt.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2009
dec.
nov.
szept.
aug.
júl.
jún.
máj.
ápr.
márc.
febr.
jan.
2008
dec.
nov.
okt.
szept.
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.