Re: Issue 100 Zero-Edits Counter Proposal

On Mon, Apr 12, 2010 at 7:13 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> This proposal is also available in HTML format for easier reading at <
> http://www.xanthir.com/:4ku >.
>
> Issue 100 Counter-Proposal
> ==========================
>
> Summary
> -------
>
> There is no problem, and no change should be made to the spec.
>
> Rationale
> ---------
>
> Several rationales are given in the Issue 100 Change Proposal for
> removing @srcdoc:
>
> 1. @srcdoc doesn't provide adequate protection
>
> 2. @srcdoc escaping requirements are difficult
>
> 3. @srcdoc has bad fallback
>
> 4. There are existing alternatives to @srcdoc
>
> 5. @srcdoc is unneeded by the blogging community
>
> ### @srcdoc doesn't provide adequate protection ###
>
> This objection is irrelevant for multiple reasons.
>
> First, this is not an objection against @srcdoc.  @srcdoc is a
> convenient way to get content to interact with the sandbox security
> model, nothing more.  If the sandbox security model doesn't provide
> adequate protection, failures should be raised as bugs against it
> specifically.  Changing or removing @srcdoc will have no effect on the
> reliability of the sandbox security model.
>
> Second, the types of things that were listed as not being protected
> against, such as SQL injection, are entirely outside the scope of
> HTML.  **No technology within HTML can possibly address them.**
> Preventing an injection attack against your database, for example, is
> the responsibility of the database itself, or of the language
> interfacing with that database.
>

Actually, no, it is relevant because it takes into account the
state-of-the-art when it comes to securing web sites, as practiced and
encouraged today.

Securing a web site requires more than just ensuring that script can't
be injected. By providing security for only one form of potential
vulnerability, we give the impression, especially to the more naive
user and developer, that the use of srcdoc provides a level of
security it doesn't, and can't, provide.

I believe that srcdoc, in this case, is not only not helpful, it is
potentially harmful. It's better that people use whatever is built
into the tools they use, or any of the libraries--server side and
client--that provide protection. Protection not only relevant today,
but also relevant for new exploits discovered tomorrow.

> ### @srcdoc escaping requirements are difficult ###
>
> When used in an HTML page, the escaping requirements for @srcdoc are
> trivial.  You have to replace " with &quot; and & with &amp;.  The
> latter has no security implications if it's forgotten; it's merely to
> prevent words following an & from accidentally being interpreted as
> entity references.  The former is important for security, but it
> should also fail very quickly and very obviously if it is left out -
> the very first post containing an unescaped " (and thus truncating
> itself and dumping the rest of the contents into the element's tag
> directly) will make it painfully obvious both that there is a problem
> and how to solve it.
>

You say trivial, but even some relatively experienced developers have
a hard time understanding the issues associated with escaping. We're
adding a level of  unnecessary of complexity.
> When used in an XHTML page, the escaping requirements may be slightly
> more involved.  If so, then it is a weakness of XML, not of @srcdoc.
> In any case, Issue 103 apparently resolves the issue adequately, by
> specifying exactly what additional characters need to be escaped for
> @srcdoc to be safely used in XML.  (Note: I'm not sure how many, if
> any, of these additional characters are necessary to escape for
> security purposes, and how many just need to be escaped to ensure
> adequate display of the content.)
>

I believe it would be simpler to remove srcdoc than to remove XML.

But your answer also demonstrates the problem:

"Note: I'm not sure how many, if any, of these additional characters
are necessary to escape for  security purposes, and how many just need
to be escaped to ensure  adequate display of the content."

If you don't know, a member of the team designing the next version of
HTML, including XHTML, how can we ask the average developer to use
this attribute, correctly?

> ### @srcdoc has bad fallback ###
>
> This objection has multiple levels.
>
> First, in a browser which doesn't understand @srcdoc at all, the
> <iframe>'s @src attribute is instead used to obtain the contents for
> the frame.  This is, in general, good fallback behavior - @srcdoc is
> intended to be identical to using @src, just without the additional
> network request.
>

In the browser that doesn't understand srcdoc, it also doesn't
understand the new sandboxing model, and that the contents of the src
attribute has to be secure, either. So no, it is not a true fall back.

> The second level, again, has to do with the sandbox security model
> itself, and thus has nothing to do with @srcdoc itself.  In browsers
> which also don't understand @sandbox, the @src fallback will execute
> in an un-sandboxed environment.  As well, the entire sandbox security
> model can be bypassed if the attacker can have the user visit the
> content's URL directly.  This is valid.  There are two possible ways
> around it:
>
> 1. Don't fallback at all - have the document pointed to by @src be an
> author-generated message that the browser the user is using doesn't
> support secure content.
>

I think it would be better to avoid encouraging people to add in "You
need to use a browser that can do this", as much as possible.

> ### There are existing alternatives to @srcdoc ###
>
> There were many alternatives proposed to @srcdoc in the discussion
> threads surrounding and preceding it.  The one that is most promising
> is to simply use a data: url in @src.  This has a few problems that
> make it inferior to @srcdoc:
>
> 1. data: urls have more complex escaping requirements than @srcdoc.
> All major web languages do provide an escaping function appropriate
> for urls, but it is easy to accidentally choose the wrong function.
> For example, in PHP the correct function to use is rawurlencode(), but
> the function urlencode() may be accidentally used instead.  In
> addition, despite both of these functions existing in PHP, multiple
> homebrew url-escaping functions can be found across the web, which may
> not escape everything that is necessary to escape.  Some of these
> lapses may result in non-obvious security holes that can be exploited
> by attackers, allowing arbitrary code injection into a web page.
>

I believe the problems inherent with escaping data: urls are also the
same problems that can happen with srcdoc. At least with data: urls we
won't be introducing this level of cruft into attributes.

> 2. In legacy browsers, data: urls will "fail open"; that is, they will
> display their contents even if the browser does not understand the
> sandbox security model, potentially exposing users to attack.  This
> can be mitigated by specifying a text/html-sandboxed mime type in the
> data: url, however.
>
> 3. As the data: url would be used in @src, there is no capability to
> fall back to another message if the browser does not understand the
> sandbox security model.
>
> 4. data: urls are usually interpreted to be a unique origin by
> default, for security.  It is possible that the `allow-same-origin`
> flag in @sandbox could be used to indicate that the data: url should
> be given the same origin as the outer page, but this would further
> complicate the already-confusing rules about when a data: url is
> same-origin and when it is unique-origin.
>
> ### @srcdoc is unneeded by the blogging community ###
>
> The creator of Wordpress, Matt Mullenweg, was asked about the need for
> @srcdoc in the Wordpress software.  He responded that Wordpress
> maintains a sanitation library that appears to work adequately.
>
> This is, again, not an argument against @srcdoc, it is an argument
> against the sandbox security model.
>


No, it is actually the strongest argument of all.

We should not be adding new elements or attributes to this
specification unless there is a strong and demonstrated need, and
demand, from the community to which it is targeted. I asked Ian the
use case for this new attribute and he specifically said weblog
comments, and gave no other use case.

I brought in an _expert_ on weblogging and asked him about this form
of security. As he said, as exists as state-of-the-art, we have
superior options today. Superior options that not only prevent the one
form of exploit supposedly addressed with srcdoc, but many other forms
as well. We, as a group, should never recommend an inferior solution,
particularly as it relates to security.

We should never incorporate anything into the spec that is not only
inferior to what exists now, but must, because of the nature of HTML
release cycles, become increasingly inferior, perhaps even harmful, in
the future.

We can't incorporate every last aspect of the web into HTML. We have
to leave the pieces of the web that are best managed by other
technologies to those technologies. To do otherwise is to make of HTML
an anvil that holds us back, rather than a tool that helps us move
forward.

Shelley

Received on Tuesday, 13 April 2010 13:55:15 UTC