Re: Sandboxed iframes (was Re: Seamless iframes + CSS3 selectors = bad idea)

On Sun, 6 Dec 2009, Ian Hickson wrote:
> On Sun, 6 Dec 2009, sird@rckc.at wrote:
> >
> > ian, isnt allow-same-origin confusing? since if its same origin what 
> > stops you from linking it and bypassing those protections.
> 
> allow-same-origin is only really intended to be used with the 
> aforementioned doc="" attribute idea (eventually) and data: URIs (in the 
> meantime). The example you mention is indeed misleading.

Upon further consideration, I think I was wrong above. One example of 
where it makes sense to use allow-same-origin is in fact the exact example 
in the spec, where a widget from a third party site is iframed and this 
protects the site from being used as a vector to open pop-ups, etc. Sure, 
if the user is tricked into going to the hostile page in a straight window 
the user could get popups, etc, but so what?


On Sun, 6 Dec 2009, Maciej Stachowiak wrote:
> > 
> > The origin of a data: Document is the same as its parent browsing 
> > context's Document's origin.
> 
> It does look like HTML5 says something like that.
> 
> WebKit uses unique origins for data: URIs, which I think Gecko used to 
> do as well, but it looks like they have changed. It's a security hole to 
> use the parent's origin, if you can cause navigation to a data: URI in a 
> frame in a different-origin parent.
> 
> What HTML5 actually says is somewhat different from what you stated 
> above:
> 
> "If a Document or image was generated from a data: URL found in another
> Document or in a script
>    The origin is the origin of the Document or script in which the data: URL
> was found."
> 
> Taken literally this rule does not seem practically implementable. UAs 
> would have change their JavaScript implementations to tag every 
> JavaScript string value with an origin, to keep track of where it was 
> found if it gets passed cross-origin (e.g. via postMessage). It's also 
> possible for data: URLs not to be found in any script or document, if 
> they are created by script in appending multiple strings or taking user 
> input.
> 
> What Firefox seems to do is give a data: URL frame the same origin as 
> the frame that initiated navigating it to that data: URL. That seems 
> like a secure and implementable rule.

I've tried to fix the spec to be saner here.


On Sun, 6 Dec 2009, sird@rckc.at wrote:
> 
> Starting from abarth message:
> http://sla.ckers.org/forum/read.php?13,31377#msg-31430
> 
> Anyway, maybe I misunderstood what he said, I thought he meant in chrome it
> was a new and exclusive origin (different from the parent one) and my tests
> sort of confirmed that.
> 
> On firefox for example, the origin is something a little weird (that is
> probably the same maciej just explained). where you have a different origin
> but access to parent/opener..

Is the current spec text satisfactory?


On Sun, 6 Dec 2009, Adam Barth wrote:
> 
> IMHO, as long as we have this stand-off about the security context of 
> data URLs, we won't be able to reap the benefits of having them inherit 
> their origin and we will be saddled with the security costs (at least in 
> Firefox).  Game theoretically, that means data URLs will end up getting 
> a unique origin unless the use cases for inherited origin are so 
> compelling that developers are willing to have their site not work in 
> Safari and IE (which doesn't seem to have happened yet).

Hopefully just IE if Safari is willing to update to match Gecko (and the 
spec, assuming they're in sync now).

Is there anyone from Microsoft willing to comment either way here?


On Sun, 6 Dec 2009, Boris Zbarsky wrote:
> 
> That said "parent" is not the parent document, but whatever triggered the
> load, in the following sense:
> 
> 1) If the load happens due to a change in the src attribute of a frame
>    the origin of that frame's owner document is used.
> 2) If the load happens due to a window.location manipulation, the
>    origin of the script performing said manipulation is used.
> 3) If a link click or form submission triggered the load, the origin of
>    the ownerDocument of the <a> or <form> DOM node is used.
> 4) In some cases the origin that's used is the origin of whatever was
>    loaded in the navigation context before the data: load.  None of
>    these cases can be triggered by Web-exposed APIs.
> 
> I think that's a more or less complete list; effectively the entity 
> performing the load in Gecko code has to indicate what origin should be 
> used for the load; the above cases so indicate.  If no origin is 
> indicated a nonce origin is used.

I believe this now matches the spec (modulo #4), though the spec is much 
terser in its description.


> We do happen to think that this behavior is secure, and reasonably 
> implementable.  It does have a gotcha for website developers, however: 
> if they allow user-contributed <iframe> or <object> elements and don't 
> vet the "src" and "data" attribute, respectively, it allows the user to 
> inject scriptable content into the page's origin...  I happen to think 
> that not vetting @src and @data is a problem in any case, but apparently 
> some people don't do it.

The same problem exists with numerous other URIs, e.g. more obviously 
javascript:, but also with lesser-known ones such as vbscript: and in 
some cases about:.


On Sun, 6 Dec 2009, Adam Barth wrote:
> 
> In some sense, a site needs to vet all URLs for javascript URLs, but 
> this behavior means that every time you see "javascript:" in an XSS 
> filter, they're probably insecure unless you also see "data:" right next 
> door.

Any system relying on blacklisting URLs or schemes is just asking for 
trouble. You simply cannot do a truly secure filtering mechanism with 
anything but a pure whitelisting mechanism, where _everything_ is 
whitelisted, including URL schemes.


On Mon, 7 Dec 2009, Maciej Stachowiak wrote:
>
> I think it would need to introduce a notion of the origin that initiated 
> a load or navigation to get this right. I think that may also be 
> necessary for javascript: URIs - the way javascript: URI handling is 
> spec'd right now is kind of vague on the origin details.

What case is vague?


On Mon, 7 Dec 2009, Maciej Stachowiak wrote:
> 
> Actually, using the same algorithm WebKit uses for "about:blank" *would* 
> be universal XSS, since "about:blank" is same-origin with the parent or 
> opener regardless of who initiated the navigation. (The reason this is 
> safe for about:blank but not for data: URLs is that the attacker cannot 
> put arbitrary contents in an about:blank frame).
> 
> Our handling of javascript: URLs is a bit closer to what is desired, in 
> that we won't execute javascript: URLs at all cross-origin. However, 
> this is done by preventing them from being sent cross-origin in the 
> first place. I believe this also violates HTML5 as written - HTML5 seems 
> to require executing such JavaScript URLs in an empty environment and 
> using their string (although the wording there seems kind of vague).

That section is certainly not my best work in terms of readability, but I 
do believe it is strictly fully defined. What are the cases that are 
vague? I hesitate to change anything in this section.


On Tue, 8 Dec 2009, gaz Heyes wrote:
>
> Has an anyone raised the issue that sandboxed iframes actually enable 
> "clickjacking" when frame buster defences are applied?
> 
> <iframe sandbox="allow-forms" src="http://twitter.com/login"></iframe>
> 
> So here the spec says disable scripts but allow forms, this would render 
> a javascript frame breaker useless.

On Mon, 7 Dec 2009, Adam Barth wrote:
> 
> Frame breakers are already useless.  You need to either do what Twitter 
> does (refuse to show the page until you've verified that you're not in a 
> frame) or use X-Frame-Options: deny.

Indeed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 20 January 2010 01:05:42 UTC