mikewest / securer-contexts

Secure Contexts, but with _more_ secureness!
19 stars 2 forks source link

Unintended client storage information might leak inside a Securer context #7

Closed shhnjk closed 2 months ago

shhnjk commented 4 years ago

All resources inside a Securer context must opt-in to be in the Securer context. The opt-in is build with CORP, which also allows opt-in using CORS.

I do believe that many websites has CORS endpoint, which doesn't have any sensitive information (e.g. some public API endpoints). However, when it comes to iframes, iframe hosts active document. And I won't be surprised if some browsers will load cookie, localStorage, etc into address space proactively.

This creates an interesting attack, where attacker page with Securer context can load victim site's endpoint, which has CORS header with garbage information, but the browser loads sensitive data to iframe's address space due to iframe being active document (which could be leaked using side channel attacks, with non-Site Isolated browsers).

Are all browser implementations aligned here that loading an iframe will not proactively load sensitive data into iframe's address space?

shhnjk commented 4 years ago

Any thoughts @mikewest?

mikewest commented 4 years ago

I do think these are the kinds of hardening steps we'll want to take once we've limited the exposure of resources into an attacker's process. This includes both server-side reevaluation of endpoints and the access they grant to attackers, and client-side reevaluation of proactive data loading on the one hand, and MIME sniffing subresources (script in particular) into a navigable document on the other (I wonder how often we legitimately navigate to application/json or text/javascript, for instance...).

To the specific question, I don't believe Chromium sends cookie information to a renderer until it asks for such data via document.cookie. That said, regardless of the behavior, vendors generally should aim for process isolation between documents and their frames, which is a fairly robust defense against the attack you suggest. It's not one that COOP/COEP assumes at the moment, but my hope is that we can collectively shift that threat model over time.

shhnjk commented 4 years ago

I do believe that process isolation will solve this issue, but reality is that it's hard to do so in low memory devices such as Android. And Securer context will not know if OOPIFs are enabled for current document.

mikewest commented 2 months ago

I'm archiving this repo. I think this issue was dealt with by [CrossOriginIsolated]?