Re: <iframe doc="">

On Mon, Jan 25, 2010 at 2:09 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Mon, Jan 25, 2010 at 1:35 PM, Leif Halvard Silli
> <xn--mlform-iua@xn--mlform-iua.no> wrote:
> > 1) So, is the text/html-sandboxed itself simply a security myth - since
> > it doesn't solve e.g. SQL injection?
>
> No?  SQL injection is red herring and I still have no idea why it was
> brought up.  It is a server-side issue concerning user-input and
> server-side databases.  It it *never* something that can be affected
> by client-side measures of *any* kind, even theoretically.  It is so
> far from being relevant to the discussion as to be patently
> ridiculous.
>
>
It's not a red herring.

The use case for this thing is weblog comments. Comments have to saved
in a database, hence the very
real possibility of SQL injection. The minor security against script
injection that srcdoc provides is a drop in the bucket compared to
other security risks associated with comments.

So, srcdoc can't replace current security measures, provided by the the
software you seem to disdain. If it can't even perform a portion of the
security of the tools that you don't seem to care for, one has to ask: what
is it good for?


> 2) If not, why not data URIs? Mark-up in attributes is an anti-pattern.
> > PHP _can_ handle URI escaping. And it isn't meant that authors hand
> > code this.
>
> I'm not sure how markup in attributes is any worse than a data url,
> which contains precisely the same data and is in an attribute.  The
> only difference is the name of the attribute and the escaping
> requirements.  (There are a few practical differences between how data
> urls currently work and how @srcdoc works that can be significant, but
> they're not relevant to this particular concern of yours.)
>
> > 3)  If we really don't find data URIs satisfying, then have all
> > "tricks" other than @srcdoc been exhausted?  I am not very much into
> > the security issues here - thus I am not really certain what I
> > supposedly solve by using whether @srcdoc or a data URI. I mean,
> > malicious code could read into @srcdoc, not?
> >
> > However, when I look at e.g.
> >
> >        <iframe><p>code</p></iframe>
> >
> > in Live DOM Viewer (using Webkit), then the <p> element is rendered in
> > the DOM as text. Can children element of <iframe> still be a security
> > concern? Why? (See, I don't understand anything of this.) If it can't,
> > then isn't that something to build on? Could one have a <srcdoc>
> > element as optional child of <iframe> for keeping the code, and where
> > it could be kept unescaped? What hinders this?
>
> No, as you'd have to escape unmatched "</iframe>"s in the content,
> which is more difficult than either @srcdoc or data url escaping.
>
> ~TJ
>

Shelley