W3C home > Mailing lists > Public > public-html@w3.org > October 2010

Re: Working Group Decision on ISSUE-100 srcdoc

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 14 Oct 2010 09:23:43 -0700
Message-ID: <AANLkTikhaRzW-rKk0Y3zAwWUrVpcorggK6oqYT9eu4hz@mail.gmail.com>
To: Andrew Fedoniouk <news@terrainformatica.com>
Cc: HTML WG <public-html@w3.org>
On Wed, Oct 13, 2010 at 8:21 PM, Andrew Fedoniouk
<andrew.fedoniouk@live.com> wrote:
> I'd like to know what is conceptually wrong with rather this:
>
> <html>
>  <head>
>      <script type="text/html" id="nested">
>          ... Some <em>nested</em> content ...
>      </script>
>  </head>
>  <iframe src="#nested">
> </html>
>
> if someone really need such type of inclusion.
>
> This provides exactly same functionality as srcdoc as far as I can see
> and will not create problems with e.g. escapement of <'> and <">
> characters, etc. as in that naďve markup-inside-attribute approach.

No, it does not.  This has exactly the same issues as the most naive
solution to the problem, a <sandbox> element.  Namely, the content you
include inside the script can have an unmatched </script>, breaking it
out of the sandbox and letting anything that follows be treated as
part of the normal page.  Arbitrary XSS follows in the obvious way.

The discussion surrounding this issue went over this in depth, and my
Change Proposal quickly summarized the issues around it and several
similar solutions.  I suggest reading my Change Proposal first before
making further suggestions, as it is very likely that your idea has
already been discussed and found wanting.  This is a hard area where
the solutions are pulled in several different directions.

~TJ
Received on Thursday, 14 October 2010 16:24:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:15 GMT