Re: [EXTERNAL] Re: Need Help With Out Of Process Iframes

[Charlie Reis]

[+alexmos]

You're right that the vertical gray bars on the left group together rows that share the same process.  You can also click the row (which highlights all other rows in the same process) or look at the Process ID column (which only has a value for the first row in each process).  As another useful trick, you can double click any row and Chrome will jump to the corresponding tab, if possible.

As for office.com and sharepoint.com, I don't have the list handy but Alex should be able to help.  We don't have a procedure for joining that list if not, but Alex can comment on upcoming ways to hint to Chrome that your site might want isolation (e.g., Origin-Agent-Cluster header, Cross-Origin-Opener-Policy header, etc).

Charlie

On Wed, Jan 27, 2021 at 7:40 AM Adhithya Rajasekaran <Adhithya.R...@microsoft.com> wrote:

Hey Charlie,

Thanks for your quick response. Really appreciate it. 

1. I didn't know about the task manager. I took a quick look at it and if I understand your response correctly, is each one of the subframe groups a separate process? 
   

I marked my guess for subframes groups with 1 - 5. 

2. Regarding OOPIFs in Android, do you happen to know if Office.com or Sharpoint is included in that list? If not, is there a process to get a site added to that list?

Thanks

Adhithya

---

From: Charlie Reis <cr...@google.com>
Sent: Tuesday, January 26, 2021 10:07 PM
To: Adhithya Rajasekaran <Adhithya.R...@microsoft.com>
Subject: [EXTERNAL] Re: Need Help With Out Of Process Iframes

 

Sure, happy to help.  (In general, feel free to send questions to site-isol...@chromium.org and the larger team can help as well.)

For (1), yes, but iframes will usually only end up in a separate process if their documents are cross-site (i.e., scheme plus eTLD+1), not just cross-origin.  A https://foo.example.com iframe will share the same process as an https://example.com parent document.  (There's a feature coming where origins can request finer grained isolation, though.)  You can always check by opening Chrome's Task Manager and looking for "Subframe" rows, or visiting chrome://process-internals/#web-contents.

For (2), Site Isolation and OOPIFs are enabled for all sites on Chrome for Windows, Mac, Linux, and ChromeOS.  On Chrome for Android, Site Isolation and OOPIFs are only enabled for certain sites (e.g., those the user logs into).  Chrome for iOS uses Apple's WebKit and doesn't support OOPIFs.

You can find more info here:

https://www.chromium.org/Home/chromium-security/site-isolation

Hope that helps,

Charlie

On Tue, Jan 26, 2021 at 9:33 PM Adhithya Rajasekaran <Adhithya.R...@microsoft.com> wrote:

Hey Charles,

My name is Adhithya. I am an engineer on the Word team at Microsoft. I got your contact information from this paper - sec19-reis.pdf (usenix.org)

I have a couple of questions about Out of Process IFrameS (OOPIFs) and would love to get some help. 

1. In our app, we embed iframes from other origins. If I am reading Out-of-Process iframes (OOPIFs) - The Chromium Projects correctly, these embedded iframes are considered child frames and will be moved into a separate process if OOPIFs are enabled. Is that a correct understanding?
2. On what platforms are OOPIFs shipped and enabled by default? On what platforms are OOPIFs shipped but not enabled by default?
   

Thanks

Adhithya

[Alex Moshchuk]

On Wed, Jan 27, 2021 at 7:48 PM Charlie Reis <cr...@chromium.org> wrote:

[+alexmos]

You're right that the vertical gray bars on the left group together rows that share the same process.  You can also click the row (which highlights all other rows in the same process) or look at the Process ID column (which only has a value for the first row in each process).  As another useful trick, you can double click any row and Chrome will jump to the corresponding tab, if possible.

As for office.com and sharepoint.com, I don't have the list handy but Alex should be able to help.  We don't have a procedure for joining that list if not, but Alex can comment on upcoming ways to hint to Chrome that your site might want isolation (e.g., Origin-Agent-Cluster header, Cross-Origin-Opener-Policy header, etc).

These sites aren't currently on the list.  You can check which sites are on the list by going to chrome://process-internals/#general on an Android device.

If a user were to type a password on those sites, they would become isolated for that user, but I'm guessing login on those sites happens through some federated service (when I tried logging in, that happened through login.live.com, and live.com is on the list).  We're working on heuristics for isolating targets of those kinds of logins, and hopefully that support will be coming along in the next few milestones.

As Charlie says, we don't have a procedure for a site to join that list, but we're working on supporting a couple of ways for a site to provide hints to request process isolation.  One of them is the Origin-Agent-Cluster header, which is supported in M89+ and should roll out for M88 fairly soon as well.  This would probably be my recommendation at this point, though note that it requests finer-granted isolation (origin-based rather than site-based) and has some other side effects which you would want to be ok with (e.g., disallowing document.domain changes).  We also plan to use the presence of non-default Cross-Origin-Opener-Policy header values as another hint for process-isolating a site; that support should be ready in the next couple of releases, but I don't have an ETA at this point.  Note also that some Android devices (below a certain RAM threshold) don't utilize any site isolation at the moment due to resource constraints; this policy would apply to header-based hints as well.

FWIW, not sure if this is at all useful, but the list can also be customized by enterprise policy and/or by embedders; for example, I see that the latest Edge (edge://process-internals) adds www.bing.com and microsoftedge.microsoft.com to the list.  You could also manually add isolated sites to the list for local debugging via chrome://flags/#isolate-origins.

Hope this helps,

Alex

[Charlie Reis]

In Chromium we do treat both Spectre and compromised renderers as part of the browser threat model these days (per the Post-Spectre Threat Model Re-Think).  In Chromium-based browsers, we try to enable as much Site Isolation as we can to mitigate those threats behind the scenes, but it's still a work in progress (e.g., sites vs origins, limited resources on Android, protecting enough data, etc).  When Site Isolation is enabled for a site, that site will be better protected from any cross-site iframes it embeds, but without Site Isolation, untrustworthy iframes can sometimes be a source of risk under this new threat model.

There are a set of new HTTP headers meant to help protect sites against Spectre-like attacks even in browsers without OOPIFs (though they still rely on only iframing content you consider trustworthy in browsers without OOPIFs).  I'd recommend looking into Cross-Origin-Opener-Policy, Sec-Fetch-Site, Cross-Origin-Resource-Policy, and Cross-Origin-Embedder-Policy headers as a starting point.  COOP generally prevents scripting across windows, making it easier for browsers to use a separate process for your document.  CORP: same-origin or Sec-Fetch-Site checks on the server can help prevent sensitive data from leaking to another origin's renderer process.  COEP limits what your own document can request to make it safe to enable powerful features like SharedArrayBuffer (so it's more about limiting your own ability to attack others than protecting your own data).

Some useful references:

COOP and COEP explained

Making your website "cross-origin isolated" using COOP and COEP

+Mike West and +Camille Lamy in case they'd like to chime in more resources on these types of headers and where we're trying to improve web platform defaults for the new threat model.

Hope that helps,

Charlie

On Thu, Jan 28, 2021 at 9:58 AM Adhithya Rajasekaran <Adhithya.R...@microsoft.com> wrote:

Hello Alex and Charlie,

Thanks a lot for the quick and detailed response. I really appreciate it. 

The Chromium Task Manager seems like a super useful tool that I didn't know about. Thanks for letting me know about it. 

To give you some background/context into why I am asking these questions - I am currently doing a security review of the product and I am specifically trying to understand what type of protection is offered by adopting OOPIFs so that I can convey it to my team. In our app, we load in content from third parties (some of whom might be untrusted). We currently Iframe them. But my understanding is that Iframing untrusted content alone doesn't offer enough protection when it comes to timing-based side channel attacks like Spectre. Is my understanding correct? If we were to isolate these third party iframes into a separate process than our app's process using OOPIFs for instance, are Spectre like attacks still possible? I understand that OOPIFs are a Chromium only thing right now. Other browsers do not have this feature. 

We are currently discussing whether to adopt COOP and what kinds of things are going to break. 

Thanks

Adhithya

---

From: Alex Moshchuk <ale...@chromium.org>
Sent: Wednesday, January 27, 2021 10:17 PM
To: Charlie Reis <cr...@chromium.org>
Cc: Adhithya Rajasekaran <Adhithya.R...@microsoft.com>; site-isol...@chromium.org <site-isol...@chromium.org>
Subject: Re: [EXTERNAL] Re: Need Help With Out Of Process Iframes

 

[Mike West]

Hi Adhithya!

> CORP seems like a version of CORS. But I am not sure why another header is required.

These two mechanisms are indeed related. CORP is something like a weaker version of CORS, allowing you to assert that a given resource can or can't be loaded with a `no-cors` request. We want that weaker variant in order to avoid forcing every resource to open itself up completely via CORS. The doc at https://arturjanc.com/coi-threat-model.pdf might be helpful in explaining the threat model in a little more depth.

> COEP seems exactly like COOP.

COOP protects you from cross-origin windows by breaking the link between them. It similarly protects them from you.

COEP protects other sites' resources from you by ensuring that you cannot load them unless they opt-into being loaded cross-origin.

> if every iframe embedded in our app is isolated in another process from our main app using OOPIFs, is there still a need for these headers in Chromium?

Yes, they both protect other resources out there on the net from you, and seem like reasonable requirements for `SharedArrayBuffer` et al. If we can get to a world in which we consistently isolate frames (which isn't the case today cross-browser, or cross-platform (Chromium on desktop != Chromium on Android), then we could likely roll back some COEP requirements around framing. Until that point, however, it makes sense to have a consistent security story for the lowest common denominator.

Hope that helps!

-mike

On Mon, Feb 1, 2021 at 5:46 AM Adhithya Rajasekaran <Adhithya.R...@microsoft.com> wrote:

Hey Charlie

Thanks for the detailed response again. 

I have spent some time looking into all the four headers with that you mentioned. I feel like I understand COOP and Sec Fetch Site. CORP seems like a version of CORS. But I am not sure why another header is required. COEP seems exactly like COOP. So, it is the biggest head scratcher for me. Is there someone who is an expert in COEP that I can talk to?

Also, if every iframe embedded in our app is isolated in another process from our main app using OOPIFs, is there still a need for these headers in Chromium? I understand that we might need this for other browsers. 

Thanks

Adhithya

---

From: Charlie Reis <cr...@chromium.org>
Sent: Thursday, January 28, 2021 10:08 PM
To: Adhithya Rajasekaran <Adhithya.R...@microsoft.com>; Mike West <mk...@chromium.org>; Camille Lamy <cl...@chromium.org>
Cc: ale...@chromium.org <ale...@chromium.org>; site-isol...@chromium.org <site-isol...@chromium.org>

[Mike West]

(Apologies; resending from the correct email address.)

Hello, Adhithya!

> YouTube and other embeds.

+Artur Janc  and friends are on the hook for Google's embeddable resources, but I agree that it's unlikely that all CDNs everywhere will start sending the right headers quickly. We've started exploring alternate COEP modes which may be easier to deploy; given some feedback from Google properties and others, https://github.com/mikewest/credentiallessness/ looks promising, and is something we're aiming to poke at sooner rather than later (like, at least Origin Trial in Q2ish?).

> Is there any way in Chromium to detect in runtime if the site has been fully isolated through OOPIFs and make COEP optional in that case?

I don't think this would help. That is, even if we fully cross-origin isolate `https://evil.com/`, it can load content via `fetch(..., { mode: "no-cors" })` or `<img>` or etc. which can reveal information about cross-origin state. Again, the COEP requirement is meant to protect that cross-origin content from you, the developer who has access to SharedArrayBuffer.

-mike

On Mon, Feb 1, 2021 at 12:49 PM Adhithya Rajasekaran <Adhithya.R...@microsoft.com> wrote:

Hey Mike,

> CORP seems like a version of CORS. But I am not sure why another header is required.

These two mechanisms are indeed related. CORP is something like a weaker version of CORS, allowing you to assert that a given resource can or can't be loaded with a `no-cors` request. We want that weaker variant in order to avoid forcing every resource to open itself up completely via CORS. The doc at https://arturjanc.com/coi-threat-model.pdf might be helpful in explaining the threat model in a little more depth.

> COEP seems exactly like COOP.

COOP protects you from cross-origin windows by breaking the link between them. It similarly protects them from you.

COEP protects other sites' resources from you by ensuring that you cannot load them unless they opt-into being loaded cross-origin.

Thanks for the detailed explanation. I have a better understanding of COEP and CORP now. 

> if every iframe embedded in our app is isolated in another process from our main app using OOPIFs, is there still a need for these headers in Chromium?

Yes, they both protect other resources out there on the net from you, and seem like reasonable requirements for `SharedArrayBuffer` et al. If we can get to a world in which we consistently isolate frames (which isn't the case today cross-browser, or cross-platform (Chromium on desktop != Chromium on Android), then we could likely roll back some COEP requirements around framing. Until that point, however, it makes sense to have a consistent security story for the lowest common denominator.

Thanks for the detailed response here as well. My team at Microsoft is appreciative of all the work going on this space to protect users from Spectre like attacks. So, thanks for the team's hard work on this.  @Charlie mentioned that OOPIFs are not available iOS and in Android it is limited to a small subset of sites.  It is also my understanding that OOPIFs are only fully enabled in Chromium for Windows, Mac, and Chrome OS. So, I am fully aware of the limitations even in Chromium. I also really appreciate trying to drive towards a cross browser, cross platform solution for this problem. 

I spent some time digging into these headers more. We already have support for CORS. If there is some resource that is not CORS enabled, we should be able to adopt CORP for those resources. We should be able to adopt COOP as well. We are investigating Sec-Fetch-Site. But it looks like COEP is the one that we will have an extremely difficult time adopting. 

For example: We allow customers to embed content from other sites like YouTube. Most of these embeds are sitting inside iframes. I ran a quick test by trying to enable COEP on our main document. The embedded content doesn't load anymore because of this error

I tried to have a look at the Chromium task manager on my Windows laptop, and I noticed that YouTube was fully isolated in a separate process (if I don't try to enforce COEP)

We have several such scenarios where we are embedding content in iframes from cross site locations. IIUC, requiring COEP for embedded iframes is going to break all those scenarios and trying to get the companies that own the content to fix them might take months to years (I am not trying to say YouTube would take years to fix it. I am just talking from experience working with other companies). 

Is there any way in Chromium to detect in runtime if the site has been fully isolated through OOPIFs and make COEP optional in that case?

Thanks

Adhithya

---

From: Mike West <mk...@chromium.org>
Sent: Sunday, January 31, 2021 11:25 PM
To: Adhithya Rajasekaran <Adhithya.R...@microsoft.com>
Cc: cr...@chromium.org <cr...@chromium.org>; cl...@chromium.org <cl...@chromium.org>; ale...@chromium.org <ale...@chromium.org>; site-isol...@chromium.org <site-isol...@chromium.org>

[Charlie Reis]

Sorry for my delayed reply, and thanks Mike for chiming in!

As far as I understand it, there's no need to use COEP at all in your case, unless your site needs powerful features like SharedArrayBuffer.

The combination of severing window references with COOP and protecting your sensitive data from cross-site no-cors access (with CORP and/or Sec-Fetch-Site) should be sufficient for all browsers to protect your site's data, as long as you trust the content you load in iframes.  If you don't trust the content you iframe, then OOPIFs basically seem required, and COEP wouldn't help.

As for CORP vs CORS, keep in mind that any data you expect to be protected by CORS (e.g., a JSON URL fetched by the page) could be requested by an attacker via a no-cors <img> tag, getting the data into the renderer process where it may leak.  That's why CORP and Sec-Fetch-Site are helpful-- they prevent the response from making it to the attacker's renderer process in the first place, no matter how the request was initiated.  (Chrome tries to do its best to protect most HTML/XML/JSON by default using a built-in sniffing-based system called CORB, but this is best effort and may let some data through in some cases.)

If you can choose either CORP or Sec-Fetch-Site defenses, looking at Sec-Fetch-Site request headers (and failing the response if it's cross-site) is slightly better because server-side blocking can defeat timing attacks more effectively than client-side blocking (with CORP response headers).

Hope that helps,

Charlie

On Mon, Feb 1, 2021 at 10:42 AM Adhithya Rajasekaran <Adhithya.R...@microsoft.com> wrote:

Hey Mike,

Thanks again for the detailed response. Really appreciate it. 

> YouTube and other embeds.

+Artur Janc  and friends are on the hook for Google's embeddable resources, but I agree that it's unlikely that all CDNs everywhere will start sending the right headers quickly. We've started exploring alternate COEP modes which may be easier to deploy; given some feedback from Google properties and others, https://github.com/mikewest/credentiallessness/ looks promising, and is something we're aiming to poke at sooner rather than later (like, at least Origin Trial in Q2ish?).

I will read more today on your proposal and will get back to you with any questions. 

> Is there any way in Chromium to detect in runtime if the site has been fully isolated through OOPIFs and make COEP optional in that case?

I don't think this would help. That is, even if we fully cross-origin isolate `https://evil.com/`, it can load content via `fetch(..., { mode: "no-cors" })` or `<img>` or etc. which can reveal information about cross-origin state. Again, the COEP requirement is meant to protect that cross-origin content from you, the developer who has access to SharedArrayBuffer.

Apologies if I didn't make myself clear. We have no issues with either enabling or requesting others to enable CORS or CORP for all the cross-origin resources we use in our app (images, JS files, css files, etc.) to protect them from getting attacked by us if they do not give permission. We fortunately use our own CDN for serving assets. 

The biggest hurdle for us in adopting COEP would be third party cross site iframes that we embed (YouTube video iframe in my example below).  I have verified that many of these cross site iframes have CORS enabled. But I am finding out that enabling CORS or CORP alone for IFrames is not enough. If COEP is enabled in the main document, every single IFrame that our main document embeds is also required to implement COEP (meaning if I want to enable COEP on Word, the YouTube iframe is required to implement COEP before YouTube can be embedded into our site). If a third party iframe provides consent to be embedded in another site by providing a CORP or CORS header, I am wondering why the additional COEP implementation requirement is in place. Even if were to assume that COEP is there to isolate that iframe from the evil parent frame, wouldn't OOPIFs already offer that protection on platforms/OSs where that protection is available?

Thanks

Adhithya

---

From: Mike West <mk...@chromium.org>
Sent: Monday, February 1, 2021 4:43 AM
To: Adhithya Rajasekaran <Adhithya.R...@microsoft.com>; Artur Janc <a...@google.com>