blob: 334416c026576356e89e88f90dad166260f48448 [file] [log] [blame] [view]
Lukasz Anforowicz11dbb06d2020-05-12 00:14:341# Threat Model And Defenses Against Compromised Renderers
Lukasz Anforowiczf4e58ce2020-05-11 18:18:582
3Given the complexity of the browser, our threat model must use a "defense
4in depth" approach to limit the damage that occurs if an attacker
5finds a way around the Same Origin Policy or other security logic in the
6renderer process.
7For example, the combination of Chrome's sandbox, IPC security checks, and Site
8Isolation limit what an untrustworthy renderer process can do. They
9protect Chrome users against attackers, even when such attackers are able to
10bypass security logic in the renderer process.
Lukasz Anforowicz11dbb06d2020-05-12 00:14:3411For other arguments for the "defense in depth" approach and why our
12threat model covers compromised renderers, please see
13[the Site Isolation motivation](https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Motivation).
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5814
15In a compromised renderer, an attacker is able to execute
Lukasz Anforowicz11dbb06d2020-05-12 00:14:3416arbitrary native (i.e. non-JavaScript) code within the renderer
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5817process's sandbox. A compromised renderer can forge
18malicious IPC messages, impersonate a Chrome Extension content script,
19or use other techniques to trick more privileged parts of the browser.
20
21The document below gives an overview of features that Chrome attempts to
22protect against attacks from a compromised renderer. Newly discovered
23holes in this protection would be considered security bugs and possibly
24eligible for the
25[Chrome Vulnerability Rewards Program](https://www.google.com/about/appsecurity/chrome-rewards/).
26
27[TOC]
28
29
30## Site Isolation foundations
31
32Most of the other protections listed in this document implicitly assume that
33attacker-controlled execution contexts (e.g. HTML documents or service workers)
34are hosted in a separate renderer process from other, victim contexts.
35This separation is called
36[Site Isolation](https://www.chromium.org/Home/chromium-security/site-isolation)
37and allows the privileged browser
38process to restrict what origins a renderer process is authorized to read or
39control.
40
41The privilege restriction can be implemented in various ways - see the
42"protection techniques" listed in other sections in this document.
43One example is validating in the browser process whether an incoming IPC can
44legitimately claim authority over a given origin (e.g. by checking via
45`CanAccessDataForOrigin` if the process lock matches).
46Another example is making sure that capabilities handed over to renderer
Lukasz Anforowiczdcd286f2020-08-18 22:16:3147processes are origin-bound (e.g. by setting `request_initiator_origin_lock`
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5848on a `URLLoaderFactory` given to renderer processes).
49Yet another example is making security decisions based on trustworthy knowledge,
50calculated within the privileged browser process (e.g. using
51`RenderFrameHost::GetLastCommittedOrigin()`).
52
Lukasz Anforowicz11dbb06d2020-05-12 00:14:3453Compromised renderers shouldnt be able to commit an execution context
54(e.g. commit a navigation to a HTML document, or create a service worker)
55in a renderer process hosting other, cross-site execution contexts.
56On desktop platforms all sites (site = scheme plus eTLD+1) should be isolated
57from each other.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5858On Android, sites where the user entered a password should be isolated
59from each other and from other sites.
60
61**Known gaps in protection**:
Lukasz Anforowicz11dbb06d2020-05-12 00:14:3462- No form of Site Isolation is active in Android WebView.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5863 See also https://crbug.com/769449.
64- No form of Site Isolation is active in content hosted within
65 `<webview>` HTML tags. See also https://crbug.com/614463.
66- Frames with `<iframe sandbox>` attribute are not isolated
67 from their non-opaque precursor origin.
68 See also https://crbug.com/510122.
Lukasz Anforowicz11dbb06d2020-05-12 00:14:3469- `file:` frames may share a process with other `file:` frames.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5870 See also https://crbug.com/780770.
71
72
73## Cross-Origin HTTP resources
74
75Compromised renderers shouldn't be able to read the contents (header + body) of
76a cross-site HTTP response, unless it is a valid subresource needed for
77compatibility (e.g., JavaScript, images, etc), or is successfully allowed via
78CORS.
79
80Protection techniques:
81- Enforcing
82 [Cross-Origin Read Blocking
83 (CORB)](https://www.chromium.org/Home/chromium-security/corb-for-developers)
84 in the NetworkService process
85 (i.e. before the HTTP response is handed out to the renderer process).
86- Only allowing the privileged browser process to create
87 `network::mojom::URLLoaderFactory` objects that handle HTTP requests.
88 This lets the browser process carefully control security-sensitive
89 `network::mojom::URLLoaderFactoryParams` of such factories (such as
Lukasz Anforowiczdcd286f2020-08-18 22:16:3190 `request_initiator_origin_lock`, `is_corb_enabled`, `disable_web_security` or
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5891 `isolation_info`).
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5892
93**Known gaps in protection**:
94- Content types for which CORB does not apply
95 (e.g. `image/png`, `application/octet-stream`) are not protected by
96 default. We recommend that HTTP servers protect such resources by
97 either serving a `Cross-Origin-Resource-Policy: same-origin` response header
98 or validating the `Sec-Fetch-Site` request header.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:5899
100
101## Contents of cross-site frames
102
103Compromised renderers shouldn't be able to read the contents of cross-site
104frames. Examples:
105- Text or pixels of cross-site frames.
Lukasz Anforowicz11dbb06d2020-05-12 00:14:34106- Full URL (e.g. URL path or query) of cross-site frames.
107 Note that the origin of other frames
108 needs to be exposed via `window.origin` for legacy reasons.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58109
110Protection techniques:
111- Compositing tab contents (both for display and for printing)
112 outside the renderer processes.
113- Isolating PDF plugins.
114- Being careful what URLs are exposed in console messages.
115
116**Known gaps in protection**:
117- Mixed content console messages may disclose cross-site URLs
118 (see also https://crbug.com/726178).
119
120
121## Cookies
122
123Compromised renderers shouldnt be able to read or write
124any cookies of another site,
125or `httpOnly` cookies even from the same site.
126
127Protection techniques:
128- Renderer processes are only given `network::mojom::RestrictedCookieManager`
129 for origins within their site
130 (see `StoragePartitionImpl::CreateRestrictedCookieManager`).
131- Mojo serialization does not send any cookies from HTTP headers to the renderer
132 process (see
133 `ParamTraits<scoped_refptr<net::HttpResponseHeaders>>::Write`).
134
135
136## Passwords
137
138Compromised renderers shouldnt be able to read or write passwords of
139other sites.
140
141Protection techniques:
142- Using `CanAccessDataForOrigin` to verify IPCs sent by a renderer process
143 (e.g. `//components/password_manager/content/browser/bad_message.cc`)
144- Using trustworthy, browser-side knowledge
145 to determine which credentials to read or write
146 (e.g. `content::RenderFrameHost::GetLastCommittedURL` in
147 `password_manager::CredentialManagerImpl::GetOrigin`).
148
149
150## Security-sensitive UI/chrome elements (e.g. Omnibox)
151
152Compromised renderers shouldnt be able to influence/spoof
153security-sensitive UI elements.
154
155Examples:
156- Omnibox
157 - URL (e.g. renderer process locked to foo.com shouldnt
158 be able to trick the Omnibox into displaying bar.com)
159 - Secure / not secure chip (e.g. a renderer process locked to a HTTP
160 site shouldnt be able to trick the Omnibox into displaying a
161 HTTPS-associated lock)
162 - Content settings (e.g. a renderer process that has been granted
163 microphone access shouldnt be able to suppress the mic/camera
164 icon in the Omnibox)
165- Dialogs and prompts (for example a permissions dialog asking to allow
166 a site to show notifications)
167 - Origin in dialogs (e.g. a renderer process locked to foo.com
168 shouldnt be able to trick the Omnibox into displaying a bar.com
169 URL in permission dialogs)
170
171Protection techniques:
172- `RenderFrameHostImpl::CanCommitOriginAndUrl` verifies that the renderer
173 process is able to commit what it claims, and kills the process otherwise.
174- Work-in-progress: calculating the origin in the browser process,
175 before a navigation commits (https://crbug.com/888079).
176
177
178## Permissions
179
180Compromised renderers shouldnt be able to gain permissions without user
181consent.
182
183Examples: microphone access permission, geolocation permission, etc.
184
185Protection techniques:
186- Requesting permissions based on browser-side knowledge of frame's origin
187 (e.g. see `GeolocationServiceImplContext::RequestPermission`).
188
189
190## Web storage
191
192Compromised renderers shouldn’t be able to read from or write into
193storage of another site.
194
195Examples of protected storage technologies:
196- localStorage
197- sessionStorage
198- indexedDB
199- blob storage
200- webSQL
201
202Protection techniques:
Lukasz Anforowicz482366732020-05-12 01:34:54203- Using `CanAccessDataForOrigin` to verify IPCs sent by a renderer process
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58204 (e.g. see `StoragePartitionImpl::OpenLocalStorage`).
Lukasz Anforowicz11dbb06d2020-05-12 00:14:34205- Binding Mojo interfaces to a single origin obtained from browser-side
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58206 information in `RenderFrameHost::GetLastCommittedOrigin()`
Lukasz Anforowicz482366732020-05-12 01:34:54207 (e.g. see `RenderFrameHostImpl::CreateIDBFactory`).
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58208
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58209
210## Messaging
211
212Compromised renderers shouldn’t be able to:
213- Spoof the `MessageEvent.origin` seen by a recipient of a `postMessage`.
214- Bypass enforcement of the `targetOrigin` argument of `postMessage`.
Lukasz Anforowicz11dbb06d2020-05-12 00:14:34215- Send or receive `BroadcastChannel` messages for another origin.
Lukasz Anforowiczcc9524172022-08-24 18:31:20216- Spoof the `MessageSender.origin`, nor `MessageSender.id` (i.e. an
217 extension id which can differ from the origin when the message is sent
218 from a content script), as seen by a recipient of a
219 `chrome.runtime.sendMessage`.
220 See also [MessageSender documentation](https://developers.chrome.com/extensions/runtime#type-MessageSender) and [content script security guidance](https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/0ei-UCHNm34).
Lukasz Anforowicz67c9cbc2022-08-30 19:18:15221- Spoof the id of a Chrome extension initiating
222 [native messaging](https://developer.chrome.com/docs/apps/nativeMessaging/)
223 communication.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58224
225Protection techniques:
Lukasz Anforowicz482366732020-05-12 01:34:54226- Using `CanAccessDataForOrigin` to verify IPCs sent by a renderer process
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58227 (e.g. in `RenderFrameProxyHost::OnRouteMessageEvent` or
228 `BroadcastChannelProvider::ConnectToChannel`).
Lukasz Anforowicz67c9cbc2022-08-30 19:18:15229- Using `ContentScriptTracker` to check if IPCs from a given renderer process
230 can legitimately claim to act on behalf content scripts of a given extension.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58231
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58232
Lukasz Anforowicz11dbb06d2020-05-12 00:14:34233## JavaScript code cache
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58234
Lukasz Anforowicz11dbb06d2020-05-12 00:14:34235Compromised renderers shouldn't be able to poison the JavaScript code cache
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58236used by scripts executed in cross-site execution contexts.
237
238Protection techniques:
Lukasz Anforowicza288a132020-05-19 17:18:22239- Validating origins sent in IPCs from a renderer process by using
240 `CanAccessDataForOrigin` in
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58241 `CodeCacheHostImpl::DidGenerateCacheableMetadataInCacheStorage`.
Lukasz Anforowicza288a132020-05-19 17:18:22242- Using trustworthy, browser-side origin lock while writing to and fetching from
243 the code cache by using `ChildProcessSecurityPolicyImpl::GetOriginLock` in
244 `GetSecondaryKeyForCodeCache` in
245 `//content/browser/renderer_host/code_cache_host_impl.cc`
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58246
247
248## Cross-Origin-Resource-Policy response header
249
250A compromised renderer shouldnt be able to bypass
Lukasz Anforowicz482366732020-05-12 01:34:54251[Cross-Origin-Resource-Policy (CORP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_%28CORP%29),
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58252which prevents or allows responses from being requested cross-origin, more
253explicitly than CORB.
254
255Protection techniques:
256- Enforcing Cross-Origin-Resource-Policy in the NetworkService process
257 (i.e. before the HTTP response is handed out to the renderer process).
258- Preventing spoofing of `network::ResourceRequest::request_initiator`
Lukasz Anforowiczbc9875032021-06-24 18:37:42259 by comparing against `request_initiator_origin_lock` in
260 `network::CorsURLLoaderFactory::IsValidRequest`.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58261
262
263## Frame-ancestors CSP and X-Frame-Options response headers
264
265A compromised renderer shouldnt be able to bypass `X-Frame-Options`
266or `frame-ancestors` CSP.
267
268For example, if example.com/page.html sends a `X-Frame-Options: deny` header,
269then it should never commit in a subframe, even if some renderers have
270been compromised.
271
272Protection techniques:
273- `X-Frame-Options: deny` is enforced in the browser process
274 via `content::AncestorThrottle`, an implementation of
275 `content::NavigationThrottle`.
276- `frame-ancestors` is enforced in a renderer process, but
277 this process is considered trustworthy in this scenario
278 (because it hosts the frame that is requesting protection).
279 See also https://crbug.com/759184 which tracks
280 moving this enforcement into the browser process.
281
282
283## HTTP request headers
284
285Compromised renderers shouldnt be able to control security sensitive HTTP
Lukasz Anforowicz17373d72021-06-28 23:19:58286request headers like `Host`, `Origin`, or `Sec-Fetch-Site`.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58287
288Protection techniques:
289- Using `AreRequestHeadersSafe` to reject `Host` and other headers that
290 should only be generated internally within the NetworkService.
Lukasz Anforowiczbc9875032021-06-24 18:37:42291- Preventing spoofing of `network::ResourceRequest::request_initiator`
292 by comparing against `request_initiator_origin_lock` in
293 `network::CorsURLLoaderFactory::IsValidRequest`.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58294
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58295
296## (WIP) SameSite cookies
297
298Compromised renderers shouldnt be able to send a cross-site HTTP request with
299SameSite cookies.
300
301**Work-in-progress / not protected today**.
302
303TODO(morlovich): Add details. I assume that this requires trustworthy
304|request_initiator| (similar to the `Origin` header), but probably more
305than that.
306
307See also https://crbug.com/927967.
308
309
310## (WIP) User gestures / activations.
311
312Compromised renderers shouldn't be able to spoof user gestures to perform
Lukasz Anforowicz11dbb06d2020-05-12 00:14:34313actions requiring them:
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58314
Lukasz Anforowicz11dbb06d2020-05-12 00:14:34315- A compromised renderer should not be able to forge a gesture that affects
316 the trusted browser UI. For example, a compromised renderer should not be
317 able to interact with the Omnibox or the WebBluetooth chooser.
318
319- A compromised renderer should not be able to forge a gesture that grants
320 extra capabilities to a web origin. For example, a compromised renderer
321 should not be able to open an unlimited number of popup
322 windows by forging user gestures.
323 **Work-in-progress / not protected today** - see https://crbug.com/848778.
Lukasz Anforowiczf4e58ce2020-05-11 18:18:58324
325
326## Web Accessible Resources of Chrome Extensions
327
328Compromised non-extension renderers shouldn’t be able to access
329non-web-accessible-resources of a Chrome Extension.
330
331Protection techniques:
332- Navigations: Enforcement in the browser process
333 via `extensions::ExtensionNavigationThrottle`, an implementation of
334 `content::NavigationThrottle`. This relies on non-spoofability
335 of `content::NavigationHandle::GetInitiatorOrigin`.
336- Subresources: Enforcement in the browser process via
337 `ExtensionURLLoaderFactory::CreateLoaderAndStart`. This relies
338 on process boundaries and therefore doesn't rely on non-spoofability
339 of `network::ResourceRequest::request_initiator`.
340
341
342## Non-Web resources
343
344Compromised *web* renderer processes shouldnt be able to access
345*local* resources (e.g. `file://...` or `chrome://settings`).
346
347Protection techniques:
348- TODO(lukasza, nasko): need to research
349
350
351## Android-specific protection gaps
352
353Due to resource constraints, on Android platforms only some sites get a
354dedicated renderer process, isolated from other sites.
355(Current heuristic is to isolate the sites where the user has entered a password
356in the past.)
357This means that some sites are hosted in a renderer process that is
358*not* locked to any particular site. If an attacker compromises
359an unlocked renderer process, they may try to abuse protection gaps listed
360below.
361
362**Known gaps in protection**:
363- When `CanAccessDataForOrigin` runs on the IO thread, it cannot protect
364 isolated sites against being accessed from an unlocked renderer process.
365 Some web storage protections depend on `CanAccessDataForOrigin` calls
366 on the IO thread.
367 See also https://crbug.com/764958.
Lukasz Anforowicz0481d82f2020-05-27 22:08:24368
369
370## Renderer processes hosting DevTools frontend
371
372If an attacker could take control over the DevTools frontend then the attacker
373would gain access to all the cookies, storage, etc. of any origin within the
374page and would be able to execute arbitrary scripts in any frame of the page.
375This means that treating the DevTools renderer as untrustworthy wouldn't in
376practice offer additional protection for the same-origin-policy.
377
378Because of the above:
379
380- Chrome ensures that the DevTools frontend is always hosted in a renderer
381 process separate from renderers hosting web origins.
382- Chrome assumes that the DevTools frontend is always trustworthy
383 (i.e. never compromised, or under direct control of an attacker).
384 For example, when the DevTools process asks to initiate a HTTP request on
385 behalf of https://example.com, the browser process trusts the DevTools
386 renderer to claim authority to initiate requests of behalf of this origin
387 (e.g. attach SameSite cookies, send appropriate Sec-Fetch-Site request header,
388 etc.).