1222804 - Iframe sandboxing breaks SSL error pages

Status: RESOLVED WORKSFORME

(Firefox :: Security, defect)

Description

[Khalil Zhani]

<iframe sandbox src="https://wrong.host.badssl.com/" height="600" width="600" />

Comment 1

[:Gijs (he/him)]

Are you just talking about the error page being broken because scripting is disabled by the iframe sandbox? Or something else? Your summary and description are not clear on this.

Comment 2

[Khalil Zhani]

Yeah, I meant the error on the page.

Comment 3

[:Gijs (he/him)]

dkeeler/Tim, ideas about what we could do here? I am uncomfortable with trying to special-case these pages because that feels like opening up another vector to attack the sandbox / privilege escalate.

Not entirely convinced this needs to remain sec-sensitive. No compromise of the machine or user data is achieved, nor is there a demonstration that this can somehow be used for spoofing or whatever - it's our error page and the page has even less control over it than usual considering it's broken...

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler]]

We don't allow adding overrides for framed sites anyway, so I'm not sure this is a big deal - more of a UX papercut (additionally, the message about HSTS is misleading and irrelevant). I would open up this bug, but it looks like I don't have permissions to do so.

Comment 5

[:Gijs (he/him)]

We could potentially use <noscript> and hide everything else, and put in a generic error message for both about:certerror and about:neterror? That would minimize confusion and be simpler to implement than trying to get everything to work.

Comment 6

[Boris Zbarsky [:bzbarsky]]

<noscript> seems pretty reasonable at first glance if we don't want to make exceptions for error pages from sandboxing.

> We don't allow adding overrides for framed sites anyway

Doesn't matter much.  Consider a sandbox="allow-popups" iframe doing:

  <a href="https://wrong.host.badssl.com/" target="_blank">Click me</a>

(or equivalent with window.open if sandbox="allow-popups allow-scripts").  Now you have a toplevel page which has the null principal (because it's not allow-same-origin) and is an SSL error.

But really, seems like we should not apply the docshell's sandboxing flags to error pages.  This doesn't seem like it would be hard to fix....

Comment 7

[:Gijs (he/him)]

This seems to be wfm now, Johann, can you confirm?

Comment 8

[Johann Hofmann [:johannh]]

If the issue was that the error page is not functioning correctly in sandboxed iframes then yeah, this was fixed somewhere else but I don't remember exactly which bug.