Re: <iframe doc="">

Kornel, Mon, 25 Jan 2010 16:24:39 +0000:

> To understand this you must first understand relationship between 
> @srcdoc with @sandbox. You seem to be debating merit of @sandbox, but 
> insisting that it is issue of @srcdoc.
> 
> Sandbox for comments and ads might still be implemented without 
> @srcdoc, for example with src="data:text/html-sandboxed,…" or 
> external file with appropriate MIME type. Do you oppose inclusion of 
> markup in @srcdoc attribute (which is one of the options, mainly for 
> authors' convenience), or any use of <iframe> for sandboxing of 
> content?

1) So, is the text/html-sandboxed itself simply a security myth - since 
it doesn't solve e.g. SQL injection?

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.

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?

I just note in passing that the following should be a pretty "dead" 
code:

<iframe src="document">
  <script>
    <plaintext><p>Mark-up-1</p>
  </script>
</iframe>

(Only IE requires the <script> element as wrapper in order to end the 
<plaintext> effect.)
-- 
leif halvard silli