WIP: Add baseURI leak from sandboxed iframes

[alesandroortiz]

As described in these Chromium bugs:
https://issues.chromium.org/issues/330744612
https://issues.chromium.org/issues/40867031

And this WHATWG HTML spec issue:
whatwg/html#9025

An opaque-origin iframe can read the closest page's URL via document.baseURI. Due to compatibility concerns, this probably won't be fixed anytime soon.

[alesandroortiz]

Feedback very welcome (first time contributor).

Not sure about best title for doc, or how to structure this within other files. For example, window.ancestorOrigins could also be used in a similar fashion (limited to origins), so not sure if there's a more generic page title that might work for similar leaks.

[NDevTK]

Regarding leak the closest http(s):// origin document's URL shouldn't that be leak the **initiators** closest http(s):// origin document's URL due to the change in https://groups.google.com/a/chromium.org/g/blink-dev/c/qhl64uMLjGA/m/SiugtWfvBAAJ

[terjanq]

Thanks for contributing! I left some comments and suggestions.

There are more leaks coming from sandboxed iframes so let's rename the new page to /sandboxed-iframes.md.

Also don't forget to add yourself to the contributors page!

[terjanq]

Suggested change

An iframe loaded with `about:srcdoc` and sandboxed without `allow-same-origin` (i.e. has opaque origin) can read `document.baseURI` to leak the closest http(s):// origin document's URL.

Iframes with opaque URLs (`about:srcdoc`) inherit their initiator's (in most cases, a direct ancestor) base URL. It can be read via `document.baseURI` property which contains the full URL of the initiatior. Currently, the behavior is preserved even for sandboxed iframes without `allow-same-origin`. This is problematic if the rendered content is untrusted and the URL contains sensitive information.

[alesandroortiz]

Thanks for the rewrite. It's a bit more nuanced in HTML spec + Chromium (need to check Firefox), since about:blank behaves differently than about:srcdoc. I'll work from your rewrite and expand this to explain behaviors separately in separate commit.

[terjanq]

Suggested change

	This also works in nested frames, with the baseURI value set to the closest document's URL that has an http(s):// origin. For example, nesting multiple `about:srcdoc` within `https://example.com/path?query#hash` will still leak the full `example.com` URL.
	The behavior is inherited, which means that each nested opauqe document will inherit the `document.baseURI` from the first non-opaque initiator.

[alesandroortiz]

This isn't strictly true for about:srcdoc. It's more nuanced (by my count there's about 4 possible behaviors), so I'll expand on this in separate commit. I should have expanded on this from the first commit, sorry about the lack of depth here.

[terjanq]

Suggested change

	* HTML specification fix [^html-spec-9025]
	* Browser fixes: [^crbug-40867031] [^crbug-330744612]
	* Application mitigation: Applications should avoid having sensitive information in URL if the page may include sandboxed `about:srcdoc` iframes with untrusted data.
	Applications should avoid using opaque iframes to render untrusted code. Browsers are researching ways of mitigating the issues with sandboxed iframes [^html-spec-9025] [^crbug-40867031] [^crbug-330744612].

[alesandroortiz]

Opaque sandboxed iframes are relatively safe to use in many cases, such as iframes with content loaded from a separate domain (e.g. googleusercontent.com). Origins can still be leaked via location.ancestorOrigins, but full URLs can be protected.

Does the following work better, to scope mitigations based on what needs to be protected?

To prevent leaking full URLs, applications should avoid using opaque iframes with about:srcdoc to render untrusted code.
To prevent leaking URL origins, applications should avoid using opaque iframes to render untrusted code.
Browsers are researching ways of mitigating the issues with sandboxed iframes [^html-spec-9025] [^crbug-40867031] [^crbug-330744612].

[terjanq]

I generalized the statement to also cover risks from data:, sandboxed blob: and srcdoc. The word opaque isn't well defined anywhere, but opaque usually refers to documents not loaded from network.

[terjanq]

We usually add a hintbox informing about what browsers are affected. See an example in https://xsleaks.dev/docs/attacks/cache-probing/#defense

[alesandroortiz]

Will update in separate commit.

[alesandroortiz]

@terjanq Thanks for review!

Also don't forget to add yourself to the contributors page!

Added now, thanks for reminder.

Working on pending suggestions shortly.

[alesandroortiz]

Regarding leak the closest http(s):// origin document's URL shouldn't that be leak the **initiators** closest http(s):// origin document's URL due to the change in https://groups.google.com/a/chromium.org/g/blink-dev/c/qhl64uMLjGA/m/SiugtWfvBAAJ

@NDevTK Thanks for review! It's a bit more nuanced. I should have mentioned this in the page, so will do so in future commit. See #169 (comment)

[alesandroortiz]

WIP changes

I made several substantial updates based on feedback, but still have some TODOs (included in doc) pending verification of behavior and code analysis.

I'll try to get it ready for review again sometime next week.

Thanks for feedback so far!

[NDevTK]

A similar issue looks to exist with document.referrer leaks even with <iframe referrerpolicy="no-referrer" sandbox="allow-scripts"></iframe>

[alesandroortiz]

A similar issue looks to exist with document.referrer leaks even with <iframe referrerpolicy="no-referrer" sandbox="allow-scripts"></iframe>

Is this a known issue in HTML spec or any browser? Might be worth opening issues on respective trackers if not known.

[NDevTK]

Looks WAI per https://issues.chromium.org/40707801 although if baseURI every does get restricted might be worth looking into.