Is iframe blocked by default?

[DanielHerr]

It seems like there are instances where allowing embedding iframes would be desired, like letting users put YouTube videos in a document. There could be an option to allow embedding, maybe also with the ability to whitelist origins, restrict capabilities, etc.

[mozfreddyb]

I can see that some people may want to allow iframes (though likely not in user-generated content). In contrast to other elements that we don't allow, this at least wouldn't cause XSS (but spoofs, with an iframes executing top.location = spoofURL). 🤔 🤔 🤔

[mozfreddyb]

@otherdaniel and I met and agreed that this might be a useful feature, albeit for a later version.

FWIW; I can see your use cases of allow-listing origins in CSP (e.g., using child-src / frame-src) and restricting capabilities in Permissions Policy.

[Nicd]

Does this mean that inserting an iframe using setHTML is currently not possible? Even if it's mentioned in allowList.

[mozfreddyb]

Our threat model strictly states that we do not ever want any XSS. The Sanitizer needs to guarantee that.
What should it do for <iframe src=javascript:alert(document.domain)>?

[Nicd]

Ah, I assumed that was only guaranteed for the default configuration. Good point. I was only wondering why inserting an iframe didn't work with setHTML, but that example shows it would have defeated the entire purpose. Thanks!

[fabiospampinato]

@DanielHerr @Nicd If you'd like to experiment with this I've written an implementation of a ~subset of the Sanitizer API with support for iframes, precisely because for my use case I also need to support embedding youtube videos and the like. It's still work in progress though.

Our threat model strictly states that we do not ever want any XSS. The Sanitizer needs to guarantee that.
What should it do for <iframe src=javascript:alert(document.domain)>?

@mozfreddyb I think an approach could be to remove the src attribute if it's a javascript or data url, like it happens for a[href] basically, and also ensure that there's a strict-enough sandbox attribute set on the iframe. If you do that how could you get XSS?

[mozfreddyb]

I think you are glossing over a couple of things.
I suppose we could insert a "funky element handling" rule for iframe elements and src to ensure that the URL is not data or javascript, but then what if people want data (given that it's cross-origin)?

What about srcdoc?
Do we want to parse & sanitize the srcdoc content? Do we want to allow <iframe src> for same- & cross-origin resources?
Only for some? How would that work?

I'm eager to hear your suggestions.

[fabiospampinato]

@mozfreddyb I don't know the right answers to those questions, what I know is that being able to embed some safe iframes is essential for some applications, and safe iframes exist, so that makes the current Sanitizer API unusable for those applications, so that should be addressed. From my point of view unnecessary limitations should be deleted other time.

but then what if people want data (given that it's cross-origin)?

I don't know how to detect safe data urls, I'm fine with just deleting them all on iframes, that's better than deleting the entire iframe. Once this is figured out I suppose those should be sanitized if possible, and deleted otherwise.

What about srcdoc?
Do we want to parse & sanitize the srcdoc content?

I've never seen that used, I guess it could just be deleted until a more sophisticated logic can be figured out and implemented, if we want to go there.

Do we want to allow <iframe src> for same- & cross-origin resources?

Possibly this should be configurable. Perhaps more generally a set of origins that can be linked to should exist and all urls matched against that. Perhaps the list of origins should be scoped to specific tag names too. If the iframe is sandboxed I'm not sure whether the url is same-origin or cross-origin matters.

Just some thoughts, as of today I can't use the Sanitizer API for my application. At this point it doesn't really matter much to me if this is changed or not, but I think it should be.

[Sora2455]

@fabiospampinato Under what circumstances do you need to show iframes from unsafe arbitrary strings of HTML? If you intend to show them, can't they be generated in trusted HTML strings? Or perhaps you could use a tiny wrapper custom HTML element, with "allowCustomElements" set to true in the sanitizer?

[annevk]

Allowing iframe (and elements like it) comes with these problems:

• postMessage()
• Navigation and inspection of other nested documents
• Generally gives the opportunity to attack the embedder through side channels

I would not consider them safe, but that they do stay shy of direct script execution so perhaps it should be possible.

[annevk]

We should discuss this. I do tend to agree with @fabiospampinato that this is important. I see these options as the most plausible:

1. We "funky element" (this needs a better name) it and block src="javascript:..." and srcdoc. I don't think data: URLs are any worse than an arbitrary cross-origin URL, but willing to be persuaded. Sanitizing srcdoc exposes us to re-parsing attacks and seems like it would be too much for v1. Again, willing to be convinced.
2. We block iframe completely and introduce some kind of safe iframe policy in v2 (probably along the lines of 1). This is essentially 1, but by default you do not get iframe at all.

Having written them down, I tend to prefer 1, even though that would mean I would personally end up putting iframe into blockElements almost always.

(Some more esoteric options came to mind as well, such that srcdoc could be allowed if sandbox was specified, but that's too magic I think.)

[mozfreddyb]

We discussed this in the meeting again, though with no immediate consensus. We'll explore a "disallow XSS in the same document only" for now and will see how far that gets us.