Sandboxed iframes without allow-same-origin and with about:blank or about:srcdoc urls should not inherit a fallback base url.

[wjmaclean]

https://html.spec.whatwg.org/multipage/urls-and-fetching.html#fallback-base-url

When an iframe is sandboxed, without allow-same-origin, and has either an about:blank or about:srcdoc url, allowing it to inherit a base url from its parent or initiator is insecure. It makes more sense for the iframe to just use its src url as the base url when sandboxed. The spec, linked above, is not specific on this case.

Current behaviors: (without allow-same-origin)

Spec: Currently the spec does not seem to prohibit Documents in a sandboxed iframe from inherit the base URL (see https://html.spec.whatwg.org/multipage/urls-and-fetching.html#:~:text=The%20fallback%20base%20URL%20of%20a%20Document%20object%20document)

Chrome does not share the base URL with a sandboxed iframe.

Both FireFox & Safari do share the base URL with a sandboxed iframe.

Example:

<iframe sandbox srcdoc="console.log(document.baseURI);"></iframe>

In this case, the console output in the frame is just "about:srcdoc".

[wjmaclean]

Clarification: regarding Chrome's current behavior ...

1. Chrome currently exposes the base URL for sandboxed srcdoc but not for sandboxed about:blank.
2. We encountered some compatibility issues when trying to remove it from sandboxed srcdoc, which may require investigation.
3. For now, standardizing on not exposing the base URL for sandboxed about:blank seems like a good first step with minimal compat risk, since Chrome already behaves that way.
4. Might be worthwhile to update the srcdoc case in the future, if we can avoid compatibility issues.

[domenic]

Oh, oof. I'd be hesitant to go for Chromium's behavior in that case. Having the base URL inheritance-or-not be determined by sandboxing seems reasonable. Having it determined by a mix of sandboxing and the precise flavor of about: URL, seems like just a weird special case.

Can you say more about why Chromium thinks changing this behavior for sandboxed about:blank is a good idea? Otherwise I think aligning on the Firefox+Safari behavior is the best path here, as it gives a shorter path to interop and a simpler spec/implementation. Your OP says "insecure", but in what way? What is the threat model; who is attacking who, and what do they accomplish which would be changed by the special-casing?

[csreis]

For context, our concern is that the initiator's full URL (including potentially sensitive query parameters, fragments, etc) appears in the cross-origin (i.e., opaque) sandboxed frame's base URL. Web sites in practice are using sandboxed frames to intentionally host untrustworthy content in a different origin, but it's likely they don't realize that any sensitive parts of their own URL are visible to the sandboxed document.

It would be great if we could block base URL inheritance for all sandboxed frames, but we did see some sites depending on it in the srcdoc case. I'm not thrilled to regress security in the about:blank case just to be consistent, but that's certainly an option. CC'ing @arturjanc in case there's anything we need to be careful about there.

One alternative would be settling on a smaller change, where the initiator's URL is stripped of any query parameters or fragments before it is inherited as the base URL of the sandboxed frame. Those query parameters and fragments might be the most likely parts to be sensitive, and as far as I understand, they also aren't needed for resolving relative URLs, so maybe there's no need to include them in the inherited base URL for sandboxed frames.

[csreis]

The nice thing about dropping the query parameters and fragments in the sandboxed case is that it can apply equally to srcdoc and about:blank cases, and should hopefully eliminate most of the sensitive info leak without affecting any relative URL resolution behavior, but it's admittedly a bit of a heuristic. It wouldn't help protect anything sensitive in the path, for example. I still think it might be worth considering, given that at least some sites are relying on the base URL in the sandboxed srcdoc case.

Regarding the sandboxed about:blank case, though, it might not matter at all in practice whether the base URL is inherited there or not. For sandboxed about:blank, there may not be any way for the embedding page to put any content into the sandboxed frame, since it's an opaque origin, so nothing will notice if the base URL is there or not. Only extensions or developer tools could likely put content into it, and that's unlikely to be a concern.

[smaug----]

Do you have links to the issues Chrome got when trying to tweak the behavior.

I think Mozilla would be interested in changing the behavior, if we can prove it to be web compatible.

[csreis]

I'm only aware of an internal Google page at the moment, but I'm asking around to see if we know of any externally-facing pages with the same issue.

Also, I discovered there's an earlier thread about this at #8105 (which had been mentioned on an older Chromium bug I filed at https://crbug.com/1366593).