Is it safe to have sandbox="allow-scripts allow-popups allow-same-origin" on <iframe />?

31,494

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 without allow-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.

Share:
31,494
Kosmetika
Author by

Kosmetika

#SOreadytohelp

Updated on September 08, 2021

Comments

  • Kosmetika
    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
    Kosmetika over 8 years
    But I need to have possibility to execute scripts in iframe.
  • Boieriu Alexandru
    Boieriu Alexandru over 8 years
    I 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
    Namey about 8 years
    I 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
    Namey about 8 years
    One 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
    Radvylf Programs almost 5 years
    @Namey How about window.parent? That gives you access to quite a bit when allow-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 as window.parent gives full control of the parent page)
  • SilverlightFox
    SilverlightFox almost 4 years
    I 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
    joe over 3 years
    Edit: 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
    Mikko Rantalainen over 2 years
    TL;DR: allow-same-origin is unsafe for untrusted content in blob: URLs because blob: URLs inherit the parent document origin. If you put untrusted content on another toplevel domain that you then frame with iframe element you can safely use allow-same-origin.
  • Mikko Rantalainen
    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 a blob: URLs in <iframe> with allow-same-origin is unsafe because that will get the same access as the same content in the parent of that iframe element.