Repository navigation
Alternative triple-keying #2
Description
Did you consider always using the second-level frame as the third key? https://bugzilla.mozilla.org/show_bug.cgi?id=1558932#c3 outlines rationale for doing it that way.
Did you consider always using the second-level frame as the third key? https://bugzilla.mozilla.org/show_bug.cgi?id=1558932#c3 outlines rationale for doing it that way.
Activity
jkarlin commentedon Jan 24, 2020
I don't understand the bug. How does A get to attack B and C's caches? A only gets to attack AA, not AB or AC as they're different partitions.
annevk commentedon Jan 30, 2020
A can create another frame and load B in there (which will use A+B) and time navigations.
jkarlin commentedon Jan 30, 2020
Sorry, I'm still not following. Can you describe the attack you're considering in more detail?
annevk commentedon Jan 30, 2020
https://a.example.com/ embeds https://b.example.com/ where the user logs in. https://b.example.com/ loads some specific images based on the user's logged in state. https://a.example.com/ creates a second frame where it times these images.
jkarlin commentedon Jan 30, 2020
I'm assuming we're partitioning by origin for the sake of this discussion.
An image that B loads will be keyed as (a.example.com, b.example.com, b.example.com/img.png).
If A creates a same-origin frame and loads b.example.com/img.png, it will be keyed as (a.example.com, a.example.com, b.example.com/img.png) and will result in a cache miss.
If A creates another B frame, and the B frame loads the resource again, it will be a cache hit. But that's not something that A can observe.
annevk commentedon Jan 30, 2020
I'm talking about A navigating the frame to the image. I guess that could still use A's cache, but not sure if that is what happens in practice (and there might well be issues with
embed/objectthere).jkarlin commentedon Jan 30, 2020
Ah, I see. Yes, good point. IMHO onload/onerror should not be allowed for x-origin navigations by default.
The alternative proposed in the bug doesn't mitigate the problem, it just changes the circumstances in which it can happen.
Frankly, this is a good argument for including the entire ancestor chain in the key.
jkarlin commentedon Jan 30, 2020
Hmm, even if we had the entire ancestor chain in the key, a frame could still spy on its child frame by loading resources that it wants to inspect in new frames. So frankly, I think the problem isn't the key here but the fact that we allow x-origin onload/onerror.
annevk commentedon Feb 1, 2020
It could attack children, but at least not siblings or parents. (There's only load for frames and that leaks in a number of ways so I don't think we can do away with that.)
jkarlin commentedon Feb 3, 2020
I want to take a closer look at deprecating load for x-origin frames and adding a random delay before calling it. Maybe years down the road we could phase it out entirely.
What other leaks are you aware of?
annevk commentedon Feb 4, 2020
Enumerating frame children in various ways, observing identity changes to the cross-origin
Locationobject (this might be fixable by keeping a single proxy of sorts). Also, I think they currently delay the load event of the parent, so you'd have to change that which might break a lot of scripts in the wild.jkarlin commentedon Feb 4, 2020
Thanks!
My take is that we want to isolate all origins in the page, which is what we get by appending the requesting frame to the key.
Chrome intends to use the same partitioning logic for its entire network stack (e.g., dns, socket pools, session identifiers, etc.). I don't want to compromise the third key for the cache's sake to the detriment of the rest of the stack. Especially since the compromise is due to x-origin leaks that really should be fixed anyway.
annevk commentedon Feb 20, 2020
Whenever I talk about cache I don't mean the HTTP cache exclusively, to be clear. Also, I don't think you really addressed #2 (comment) thus far.
Because of that we're considering using the entire chain as cache key.
MattMenke2 commentedon Jul 21, 2020
I don't think using top frame and highest child frame helps much. It means second-level frames can attack third-level and below, and vice versa, no?
Using the entire chain doesn't seem to help protect child frames from their parents checking if they've loaded a resource. If a.example iframes b.example, it can just iframe b.example/subresource to see if b.example has loaded that subresource, right? It does provide protections the other way around, though.
annevk commentedon Jul 21, 2020
Perhaps it would help if you explained the attacks you are interested in addressing. It's hard to evaluate what helps otherwise.
5 remaining items
MattMenke2 commentedon Jul 22, 2020
Here's an idea: For use top-frame+innermost iframes, but for iframe root resources themselves, use a special frame-only key (Can just add a bool to the key or something, to make it unique). iframes could still be used to probe redirects of iframe's main resource, but they couldn't be used to probe subresources. Could alternatively use the parent frame's key for iframes, but that seems like a bad idea to me, even if I can't find a particular reason to avoid that approach.
Link rel headers received from the iframe root resource would need to be sure to use the key used by subresources.
The big downside is that this requires yet more round trips to open an iframe, if we isolate the socket pools as well. There are mitigations against this, though. Could either preconnect using the subframe key, too, or only respect the additional bool at the cache layer, and not the socket layer, though the latter still allows other frames to probe for live connections to origins that might have been used to request subresources.
Either suggestion here does still allow all frames to probe for cross-site top-level iframes URLs loaded by any other frame - the only real advantage it offers is protecting subresources.
Anyhow, just tossing out an option to consider and knock down as not viable.
MattMenke2 commentedon Nov 2, 2020
@annevk: Is there a more public place to discuss the choice of key? We've decided to go with separating out frame responses from the disk cache, specifically to address the cache-timing issue, though everything else (including sockets) are reused between frame requests and subresource requests.
We've also starting to think we might want to use the entire ordered path to the root frame as the key (merging SameSite children with their parents), which would allow us to describe SameSite:Lax cookies in terms of the Network Partition Key, and give us a consistent (if a bit complicated) story with respect to how partitioned cookies work (both SameSite:Lax and Strict), since it sounds like that's the direction we're going in. We're planning to start the investigation by measuring frame depths, to get a rough idea of how expensive the extra keys will be - probably also a good idea to try to figure out how many more of them there will be.
This would also let FirstPartySets have a single story for how it works with cookies and everything else,.
annevk commentedon Nov 3, 2020
I think https://github.com/privacycg/storage-partitioning/issues would be the best place in terms of getting input from all the relevant stakeholders. Fetch is probably still the place where we want to standardize it.
I suspect a write-up would help since there are probably a fair number of people coming into it fresh.
Note that I'm not really convinced the current story for cookies is actually sound: httpwg/http-extensions#1288.
MattMenke2 commentedon Nov 3, 2020
I think a write-up of problems and options is a really good idea. I'll put one together when I have time, and file a storage partitioning issue with the privacy CG with a link.
MattMenke2 commentedon Nov 20, 2020
@annevk: Sorry to go back on what I said, but looks like I'm not going to have time to invest in this, as my team's focus is sites tracking users across first party contexts, while any keys beyond top frame site are strictly security/privacy issues related to sites attacking each other within a single first party context.
annevk commentedon Nov 30, 2020
Thanks for the update! Does that mean Chrome will only start using a single key for now? Should we update Fetch?
MattMenke2 commentedon Nov 30, 2020
I think we'll probably just stick with the current scheme for now, since it does provide some protections from snooping. I'd really like to see a consensus reached before we start applying First Party Sets logic to Network Partition Keys, assuming FPS makes it that far, so may push for allocating resources on this if we reach that point.
jkarlin commentedon Nov 30, 2020
Note that Chrome is still in the midst of launching its cache partitioning. But the key that we're using is <top-frame-origin, document-origin, is-iframe-navigation, url>.
The new part is the
is-iframe-navigationboolean isolates iframe navigation resources from its subresources. It's still possible to snoop on the documents loaded by other frames via the load event, but at least this prevents one from snooping on subresources.Edit: Note that we're only planning on using this extra boolean in the key in the cache, not the rest of the network stack.
shivanigithub commentedon Nov 30, 2020
<top-frame-site, document-site, is-iframe-navigation, url> and site is scheme://etld+1
jkarlin commentedon Nov 30, 2020
Ah, thank you Shivani! Yes, schemeful site, not origin.
annevk commentedon Dec 7, 2020
So I'm a bit confused, it sounds like you still plan to use additional keys for at least the HTTP cache. I'm guessing that's mainly for security. It seems worthwhile discussing the details of that further, no?
jkarlin commentedon Dec 7, 2020
Yes, the plan is to use the top-frame site and document site for the http cache, blink's memory cache, and all of the networking stack. As you say the document site gives us security wins as opposed to privacy. If we run into performance issues we may still revert back to just top-frame site.
Definitely worth discussing the details further. Our intent is still to protect frames from each other if possible. One loophole to that scheme was the load event of subframe navigations, as you pointed out. We narrowed that attack by further partitioning subframe navigation resources from subresource requests in the disk cache partitioning scheme only. This means it's still possible to detect if a warm socket or dns cache exists for the request, but at least the most revealing attack (the http cache) is limited in scope.
EGreg commentedon Nov 21, 2022
If two websites A and B want to collude to transfer information between each other, are you proposing that this can somehow be stopped by triple partitioning? It seems that there are multiple ways for them to achieve their objective:
jkarlin commentedon Nov 21, 2022
@EGreg If two origins on a page wish to exchange data, that's totally fine. We're not trying to prevent that. We're trying to prevent unauthorized/unwanted data leakage between origins on a page, which is a security concern.
Add ERR_CACHE_MISS metrics as well