What's the point of forbidding a sandboxed iframe with allow-scripts and allow-same-origin?

A reviewer has rejected my addon with the reason: Sandboxed iframes with attributes ‘allow-scripts’ and ‘allow-same-origin’ are not allowed for security reasons.

He also said that I may simply remove the sandbox attribute of the iframe, i.e. make it a normal iframe.

I would argue that this restriction is pointless, and even worse, it makes extensions less secure.

As extensions are protected by the content security policy, only explicit extension scripts may be run and no external or arbitrary scripts are possible. This applies to normal extension pages and normal frames, and sandboxed iframes (even though scripts are allowed) are no different from them.

I am fully aware that a sandboxed iframe with attributes ‘allow-scripts’ and ‘allow-same-origin’ generally means that any script can be run in it, and the script can possibly modify the sandbox attribute, making the whole sandbox breakable. However, as my extension scripts won’t do something as silly as breaking the sandbox, a sandboxed iframe is still more restrictive than a normal iframe, which is not considered unacceptable. As a result, this restriction won’t bring any help on security.

My extension runs scripts in the iframe, and it won’t work without “allow-scripts” and “allow-same-origin”. The point of using a sandboxed iframe instead of a normal iframe is for restricting form submission and top frame navigation (via link etc.). The request of replacing it with a normal iframe will break this protection and introduce security hazards.

As the policy never restrict normal frames, please re-evaluate the rationale and necessity of forbidding sandboxed iframes with attributes ‘allow-scripts’ and ‘allow-same-origin’. Thank you.

1 Like

This topic is here for more than 2 weeks. The reviewer hasn’t provide any more explanation. I submitted another temp workaround and the review is also pending without any reviewer feedback for over 2 weeks. Can anyone help with this question?

@caitlin

You mean script running in the page inside the iframe can modify its own attributes in the parent HTML document? For sure not.

Anyway, it sounds very strange. The only thing that can be an issue is if the 3rd party remote script could actually control your extensions somehow.

Could you share more info about your project here?

My project ID is webscrapbook@danny0838.addons.mozilla.org

3rd party remote scripts are NOT possible in extensions (unless an arbitrary “content_security_policy” manifest is set, which is not the case for my extension), as previously mentioned: "As extensions are protected by the content security policy, only explicit extension scripts may be run and no external or arbitrary scripts are possible. "

As NO 3rd party script is involved, there can’t be any more security issue for a sandboxed iframe that allows scripts than a normal iframe. I request that the silly restriction for addon reviewing “Sandboxed iframes with attributes ‘allow-scripts’ and ‘allow-same-origin’ are not allowed for security reasons.” should be revoked, and addons that are rejected only due to such reason should be unrejected.

I’m not sure you understand the risks enough.

3rd party remote script can be executed from simple string without any “content_security_policy” issues - simply by using browser.tabs.executeScript API. This is how most malicious addons works and the future Manifest V3 will remove this feature for this reason.

If you are loading HTTP page into iframe, than the remote page will load and run 3rd party script!

The reviewers are skilled people so if you give them bad arguments than you sound suspicious. Note that all those malicious addons are made by developers like us so they may try to persuade them the same way you do! So reviewer needs to be able distinguish who is good and who is bad!

But I agree with you regarding sandbox="allow-scripts allow-same-origin", I don’t see a problem as long as the iframe cannot communicate with your addon somehow.

You can scan for scripts related with browser.tabs.executeScript for that. I don’t think this is relevant with the iframe issue.

I don’t think this is true. The default content security policy will block all 3rd party scripts that are loaded into an extension iframe.

This is the basic logic: iframe[sandbox="allow-scripts allow-same-origin"] is no more open than a normal iframe. If iframe is considered safe enough and is generally allowed, there is no point to (generally) disallow iframe[sandbox="allow-scripts allow-same-origin"].

I do can workaround by replacing iframe[sandbox="allow-scripts allow-same-origin"] with a normal iframe, it’s just stupid and imperformant to block forms using more complicated scripts than a simple sandboxed iframe without the “allow-forms” value. And actually I have done this revision but the re-submission is still halted for more than 2 weeks—you don’t have a mechanism to review a re-submission together with the previous submission with the same reviewer?

The whole point of that requirement is to avoid giving false sense of security. If you have the sandbox attribute, it’s expected to mean that you want sandboxing. If you use combination of flags that allow removing the sandboxing at runtime, it’s better to remove the whole sandbox attribute to make it obvious that there’s no sandboxing at all.

Note that if you use combination allow-scripts allow-same-origin that allows the supposedly sandboxed code to remove the sandbox attribute at runtime so there’s zero additional security if you add the sandbox attribute.

1 Like

Actually, this should be no longer an issue in the review process.

The sandbox attribute cannot be removed from the nested page inside iframe if the loaded page comes from a different host.
More info here:

You are totally ignoring my context…

As mentioned above, iframes in an extension page are protected by the CSP and no arbitrary 3rd party scripts may run in it. Scripts run in the iframe can only come from the extension itself, and, as the extension itself doesn’t contain any code that removes the sandboxing (which can be verified by reviewing), it is impossible that the sandbox will break.

As such, your statement that combining allow-scripts allow-same-origin means no sandboxing at all is definitely false in this context—the sandbox WON’T break, and it WILL add security by forbidding form submission, top navigation, etc., than no sandbox attribute.

1 Like

I’m only responding to make sure this is clear for anyone who finds this thread: Putting allow-scripts allow-same-origin together on a iFrame is strongly discouraged and insecure.

I’m afraid this is not true.
As per the Mozilla web docs (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#sandbox):

When the embedded document has the same origin as the embedding page, it is strongly discouraged to use both allow-scripts and allow-same-origin, as that lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.

As discussed in the previously mentioned thread, this applies only to the cases when the iframe and the parent page shares the same origin.

Only then you can access parent window from the iframe (but since you are loading your own origin page, it’s considered safe, unless you are hacking yourself :slight_smile:).

If you load any other origin page in the iframe, you can’t access the parent anymore.

The documentation may have been written long ago, when such restrictions didn’t existed. We should update it.