WIP: Add baseURI leak from sandboxed iframes by alesandroortiz · Pull Request #169 · xsleaks/wiki

alesandroortiz · 2024-08-20T23:24:54Z

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 · 2024-08-20T23:27:16Z

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 · 2024-08-21T22:23:34Z

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 · 2024-08-23T08:50:43Z

+
+## Sandboxed opaque-origin about:srcdoc iframe
+
+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.


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.

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 · 2024-08-23T08:54:42Z

+
+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.


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.

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 · 2024-08-23T09:02:12Z

+* 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.


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].

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].

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 · 2024-08-23T09:25:04Z

+## Verified Browser Versions
+As of August 20th, 2024:
+* Chrome 127.0.6533.120 Stable + 129.0.6668.9 Canary
+* Edge 127.0.2651.105 Stable
+* Firefox 128.0 Stable


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

Will update in separate commit.

Co-authored-by: terjanq <terjanq@users.noreply.github.com>

alesandroortiz · 2024-08-23T22:22:31Z

@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 · 2024-08-23T22:23:56Z

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)

Some of the nuanced behavior requires re-verification, and general readability improvements are needed, hence WIP with TODOs.

alesandroortiz · 2024-08-23T23:47:11Z

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 · 2024-08-24T17:48:54Z

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

alesandroortiz · 2024-08-24T20:56:38Z

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 · 2024-08-24T21:19:17Z

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

Add baseURI leak from sandboxed iframes

1c33d78

terjanq self-requested a review August 23, 2024 08:42

terjanq reviewed Aug 23, 2024

View reviewed changes

alesandroortiz and others added 2 commits August 23, 2024 17:56

Update contributors list

eeefa86

Apply suggestions from code review

2a6b9a4

Co-authored-by: terjanq <terjanq@users.noreply.github.com>

alesandroortiz added 2 commits August 23, 2024 18:42

Rename baseuri.md to sandboxed-iframes.md

36b7035

Expand on nuanced behavior, implement feedback

cc86bee

Some of the nuanced behavior requires re-verification, and general readability improvements are needed, hence WIP with TODOs.

alesandroortiz changed the title ~~Add baseURI leak from sandboxed iframes~~ WIP: Add baseURI leak from sandboxed iframes Aug 23, 2024

alesandroortiz marked this pull request as draft August 23, 2024 23:47

Add example hint

7bea684


		## Sandboxed opaque-origin about:srcdoc iframe

		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.


		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.


	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.

Uh oh!

Conversation

alesandroortiz commented Aug 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alesandroortiz commented Aug 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NDevTK commented Aug 21, 2024

Uh oh!

terjanq left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alesandroortiz Aug 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alesandroortiz commented Aug 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alesandroortiz commented Aug 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alesandroortiz commented Aug 23, 2024

Uh oh!

NDevTK commented Aug 24, 2024

Uh oh!

alesandroortiz commented Aug 24, 2024

Uh oh!

NDevTK commented Aug 24, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

alesandroortiz commented Aug 20, 2024 •

edited

Loading

alesandroortiz commented Aug 20, 2024 •

edited

Loading

alesandroortiz Aug 23, 2024 •

edited

Loading

alesandroortiz commented Aug 23, 2024 •

edited

Loading

alesandroortiz commented Aug 23, 2024 •

edited

Loading