Closed shhnjk closed 2 months ago
Any thoughts @mikewest?
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.
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.
I'm archiving this repo. I think this issue was dealt with by [CrossOriginIsolated]
?
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?