Repository navigation
srcdoc and sandbox interaction with session history #6809
Description
First up is a simple one: Does setting srcdoc replace the current history entry or add a new one?
Chrome & Firefox: Replace if the current document url is about:srcdoc, otherwise add.
Safari: Always replace.
I'm pretty sure Chrome & Firefox are doing the right thing here and it's somewhat spec'd.
How is a srcdoc entry stored in session history? It's currently unspec'd.
Test:
- https://iframe-session-history.glitch.me/.
- Set cookie: give all responses no-store (just to stop bfcache).
- iframe-1: Set srcdoc to Math.random().
- iframe-1: Navigate to 'one' via location object.
- iframe-1: Set srcdoc to Math.random().
This creates history entries [srcdoc1, 'one', srcdoc2] in Chrome/Firefox and [srcdoc1, srcdoc2] in Safari.
Each browser behaves differently when traversing to the srcdoc entries.
Chrome: Recreates the document using the srcdoc of the iframe. As in srcdoc1 and srcdoc2 use the same source, which is different to the source srcdoc1 used when it was first created.
Firefox: Seems to store the srcdoc source along with the history entry, so srcdoc1 and srcdoc2 use different source, which is each the source they were created with.
Safari: Restores the original history entries in these places, as if the srcdoc stuff never happened.
Another test:
- https://iframe-session-history.glitch.me/.
- Set cookie: give all responses no-store (just to stop bfcache).
- iframe-1: Set srcdoc to Math.random().
- "Navigate to same origin page"
back()
Chrome: iframe empty. I guess this is because it looks at the srcdoc of the iframe which is empty, since the page has reloaded.
Firefox: Restores the iframe to its previous content.
Safari: Restores the iframe as if setting srcdoc never happened.
This seems consistent with the findings above. Firefox's model seems to make the most sense to me. Chrome's behaviour is ok I guess. Safari's behaviour is plain weird.
Activity
jakearchibald commentedon Jun 28, 2021
Something I haven't looked at yet: When going
back(), do thesrcdociframes take their CSP rules from the parent as it is now, or as it was when thesrcdocpage was created?domenic commentedon Jun 28, 2021
/cc @domfarolino @antosart for the CSP rules question. I am pretty sure that has a canonical answer as to how it should be, given recent policy container work.
antosart commentedon Jun 29, 2021
I believe the answer for CSP rules depends on the answer to the main question (whether the
srcdoccontent is reloaded when navigating back or not).If we store the content of
srcdocin history, we should also store the policies. If we reload thesrcdocattribute (which might have changed) on history navigations, then I guess we should also re-inherit the policies from the parent.I believe the currently specced behaviour is to store the policies in history for srcdoc. This is also implemented in chrome.
(This is not tested for CSP at the moment I believe, although it is for referrer-policy, see the file referrer-policy/generic/inheritance/iframe-inheritance-history-about-srcdoc.html)
jakearchibald commentedon Jun 29, 2021
Agreed.
The spec doesn't seem to cover restoring srcdoc pages at all, unless I'm missing something.
I don't think so. See the tests above – it seems like Chrome goes back to the srcdoc defined in the page.
I tested Firefox, and it does seem to store the CSP rules along with the srcdoc src, so it's like it stores the whole response. That's what I'll spec for now, and we can look at it again later if needed.
antosart commentedon Jun 29, 2021
Sorry, I just meant w.r.t. policy inheritance (which might never be called because the spec does not cover navigating back to srcdoc). And I actually was mistaken: we explicitly excluded srcdoc when storing policies in history
Also here I was referring to policies. Chrome reloads the srcdoc content from the
srcdocattribute, but stores and reloads the policies from history.Back to the original question: if we store the content of the
srcdocattribute in history, then we should probably store other attributes as well (I am thinking atsandboxfor example, orallow). I am not totally sure I am convinced that that is better than reloading everything on history navigations.jakearchibald commentedon Jun 29, 2021
I think it comes down to what you'd expect to happen here:
Should '/a' be sandboxed?
antosart commentedon Jun 29, 2021
Another good question! I am not sure.
For history navigations to srcdoc it seemed to be slightly more clear to me, in order to avoid the asymmetry of getting one attribute (srcdoc) back from history while re-parsing another one (sandbox) from the <iframe> element, hence creating something potentially inconsistent.
jakearchibald commentedon Jun 29, 2021
Yeah it's a tough one, and I don't know enough about sandboxing. How about:
It seems weird to load a non-sandboxed page into an iframe that was born with a sandbox attribute. Maybe reconnection just shouldn't happen in that case.
domenic commentedon Jun 29, 2021
That's a tough one. On the one hand, I would expect '/a' not to be sandboxed since it was originally not sandboxed when loaded. On the other hand, I worry that that could allow some sort of sandbox escape. E.g. maybe the outer page expects that once it puts the sandbox attribute on the iframe, it's safe from its contents.
This is my instinct.
[-]srcdoc interaction with session history[/-][+]srcdoc and sandbox interaction with session history[/+]annevk commentedon Jul 21, 2021
So, to summarize:
I think that sounds pretty reasonable.
cc @smaug----
jakearchibald commentedon Jul 21, 2021
I think that's still a bit weird in this case:
If we're saying that policies are stored with the history entry, that means loading page1 without sandboxing, into an iframe with the sandbox attribute set. Isn't that… confusing?
If we were starting again, I think I'd want iframe history to be cleared if safety features changed.
annevk commentedon Jul 21, 2021
Yeah it is. I wonder if clearing history upon such an action would break anything in practice. Failing that, using the sandboxing rules at the time navigate is invoked is prolly best for that case. Is this something we should consider doing better on with new features such as https://github.com/camillelamy/explainers/blob/master/anonymous_iframes.md? No breakage there yet.
cc @camillelamy
camillelamy commentedon Jul 22, 2021
I think we're envisioning to look at the attribute every time we navigate, whether history or not. I thought this is what sandbox was doing? I would find it weird that an attribute set by the parent of the iframe for security purposes could be overwritten by the iframe's action of going back. I reckon that this looks weird from the iframe point-of-view, however in this case the iframe parent's choice of security attribute should be respected. Otherwise, we might risk a sandbox escape, or loading a regular document in a crossOriginIsolated context by error for the anonymous iframe case.
11 remaining items
Make about:srcdoc to inherit PolicyContainer from history.
Make about:srcdoc traversals use policy container from history
domenic commentedon Jul 14, 2022
So what are all the behaviors this bug is covering?
I will work on some WPTs. If someone could help clarify the desired resolution for sandboxing that'd be great as well.
WPT: test srcdoc + session history interactions
jakearchibald commentedon Jul 14, 2022
Summary of the sandbox options:
Option 1: The rules from the sandbox attr are used when navigating an iframe
Pros: It's what browsers do now!
Risk: If a developer loads an unsafe page in a sandboxed iframe, then removes sandbox and loads a safe page, it's possible through traversal that the unsafe page loads without a sandbox.
Risk: If a page loads with a safe page in an iframe, then adds a sandbox to load an unsafe page, it's possible through iframe reparenting that the unsafe page loads without a sandbox.
Risk: A page loads with an unsafe page in an iframe. It's possible through iframe reparenting, that the heuristics don't quite work, and the unsafe page ends up reparenting into a 'different' iframe without a sandbox.
Risk: Inconsistent results if we start pulling iframe documents from bfcache.
Option 2: The sandbox rules are stored in the history entry
Pros: Follows what we've decided to do with srcdoc and other policy state.
Risk: It's a change in behaviour, so could be a compat issue.
Risk: The developer sets a
sandboxattribute, then traverses the iframe, and is confused that the rules aren't applied. I don't think this is a security risk. This seems less risky than option 1. Although the developer may expect stronger sandboxing to be in place, since it's a traversal it means they must have already loaded the page with no sandbox.Option 3: History clearing and & reparenting failing
This solution has two parts:
Pros: Avoids pages loading with unexpected sandbox rules.
Risk: It's a change in behaviour, so could be a compat issue.
Maybe option 2 is the right balance of safe & simple?
WPT: test srcdoc + session history interactions
WPT: test srcdoc + session history interactions
WPT: test srcdoc + session history interactions
WPT: test srcdoc + session history interactions
WPT: test srcdoc + session history interactions
WPT: test srcdoc + session history interactions
Bug 1779540 [wpt PR 34843] - WPT: test srcdoc + session history inter…
Navigation and session history rewrite
smaug---- commentedon Feb 28, 2023
I and @petervanderbeken happened to discuss about this and also prefer option 2 of those three options (and the way Firefox stores srcdoc).
Should be relatively easy to implement and hopefully not too surprising for the web devs.
Bug 1779540 [wpt PR 34843] - WPT: test srcdoc + session history inter…