Re: <iframe doc="">

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.

> 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

Received on Monday, 25 January 2010 20:10:08 UTC