Is it safe to have sandbox="allow-scripts allow-popups allow-same-origin" on <iframe />?
Solution 1
allow-same-origin
is not safe. That will give the iframe the possibility to access parent data (also local storage for example)
Also allow-same-origin
will allow the iframe to make ajax requests to the parent's apis which can also be harmful.
However, for an iframe to access parent's data, it also requires to execute scripts, so allow-same-origin
without allow-scripts
is harmless
As for the allow-popups
, there is not much unsafe stuff an iframe can do, except the fact that it can open other urls
Solution 2
As commented by Namey, allow-same-origin
will not allow the iframe to be treated as the from same origin as the parent and is safe to use (unless the parent and the iframe share the same origin, cf: warning on MDN).
As described by https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/#granular-control-over-capabilities:
The framed document is loaded into a unique origin, which means that all same-origin checks will fail; unique origins match no other origins ever, not even themselves. Among other impacts, this means that the document has no access to data stored in any origin’s cookies or any other storage mechanisms (DOM storage, Indexed DB, etc.).
Solution 3
You have the following set on your IFrame with a Blob URL/Object-URL.
allow-scripts
allow-popups
allow-same-origin
I'm assuming the contents of the IFrame are generated from user/uncontrolled input, and could contain HTML and/or script.
First, let's go through these one-by-one.
allow-scripts
This allows JavaScript code within the IFrame to run. This could be dangerous, depending on the other values set.
With allow-scripts
only, any script could
- Make AJAX requests with e.g.
fetch
, although any responses would could not be read by the IFrame. e.g. Send cross-site request forgery (CSRF) attacks, or "phone home" to the malicious's users web app. Note that contrary to popular belief, AJAX can be sent to any origin (Cross-origin writes are typically allowed
), the Same Origin Policy only prevents reading of the response, not writing. Also, it would only be able to send the same CSRF attack as an externally hosted webpage - it wouldn't be able to read the values of tokens from the parent withoutallow-same-origin
. - Automatically navigate the user away from the page with
document.location
- note this is within the IFrame, not outside of it. - Host a form (e.g. asking for username and password), to capture credentials from the user, especially effective if the attacker mimics the style of your outer side. Note this does not require
allow-forms
as the attacker can simply use JavaScript to POST the data to their own site.
allow-popups
Allows new windows/tabs to be opened from links or JavaScript. The latter will also require allow-scripts
to be set.
allow-same-origin
This allows the same origin to be used, should the origins of the documents be compatible. Note that this does not override any default origins - that is, an attacker can't host Twitter.com in an IFrame and use this to gain access to the victim's cookies or CSRF tokens within the page, nor can they simply load Twitter.com and pretend that the content was generated from the same origin as the parent.
With Blob URLs/Object-URLs, this has the affect of setting the IFrame to have the same origin as its parent, therefore letting you read and manipulate objects within the IFrame you create.
Without allow-scripts
being set, all this does on its own is allow your outer IFrame to manipulate and read objects, however, with allow-scripts
this can allow the IFrame to manipulate and read objects in the parent, i.e. your page, which is not safe.
Therefore, this setup introduces a cross-site scripting (XSS) flaw into your application due to allow-scripts
and allow-same-origin
. It would be better to consider alternative solutions to this problem that don't require allow-same-origin
. I am not sure exactly what you wish to achieve with this value from your question, but in most cases an alternative can be found.
Comments
-
Kosmetika over 2 years
I'm dynamically creating an iframe in my app, result looks as follows:
<iframe src="blob:http%3A//localhost%3A9292/0194dfed-6255-4029-a767-c60156f3d359" scrolling="no" sandbox="allow-scripts allow-popups allow-same-origin" name="sandbox" style="width: 100%; height: 100%; border: 0px;"></iframe>
Is it safe to have such sandbox configuration (especially allowing the iframe content to be treated as being from the same origin)?
-
Kosmetika over 8 yearsBut I need to have possibility to execute scripts in iframe.
-
Boieriu Alexandru over 8 yearsI know, wich makes it unsafe :) . However, why do you need allow-same-origin on iframes? I find little cases where you actually need that
-
Namey about 8 yearsI think this may be misunderstanding what allow-same-origin does? It does no treat the iframe as being from the same origin as the parent page. It treats the iframe as being from the same domain as itself (as opposed to acting as if it was a page uniquely hosted, not connected to anything else on your domain). The only risk that I have heard (and not seen demonstrated) is that an iframe could alter itself to remove its own sandboxing.
-
Namey about 8 yearsOne exception would be if your sandboxed iframe was not cross-domain (e.g., same origin as its parent), in which case it would then gain access to things like localStorage, etc?
-
Radvylf Programs almost 5 years@Namey How about
window.parent
? That gives you access to quite a bit whenallow-same-origin
is on, though the risk depends on the situation (with a system like my same-domain plugin system, the risk is very high aswindow.parent
gives full control of the parent page) -
SilverlightFox almost 4 yearsI see what you're saying, but don't forget that the blob URL (as used in the OP's case) will have the same origin as its parent. Therefore using this with
allow-scripts
is unsafe. -
joe over 3 yearsEdit: Ah, I just read your answer properly, sorry: "unless the parent and the iframe share the same origin..." I wish I could take back my downvote, but an edit is required due to strange SO rules, sorry.
-
Mikko Rantalainen over 2 yearsTL;DR:
allow-same-origin
is unsafe for untrusted content inblob:
URLs becauseblob:
URLs inherit the parent document origin. If you put untrusted content on another toplevel domain that you then frame withiframe
element you can safely useallow-same-origin
. -
Mikko Rantalainen over 2 years@Namey There's one special case you have to consider: the
blob:
URLs are special and inherit parent document as their origin: w3c.github.io/FileAPI/#originOfBlobURL – as such, putting untrusted content in ablob:
URLs in<iframe>
withallow-same-origin
is unsafe because that will get the same access as the same content in the parent of that iframe element.