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)?
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.).
You have the following set on your IFrame with a Blob URL/Object-URL.
allow-scriptsallow-popupsallow-same-originI'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.
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
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 without allow-same-origin.document.location - note this is within the IFrame, not outside of it.allow-forms as the attacker can simply use JavaScript to POST the data to their own site.Allows new windows/tabs to be opened from links or JavaScript. The latter will also require allow-scripts to be set.
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.
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
