[whatwg] some thoughts on sandboxed IFRAMEs

[Alex Russell]

AFAICT, the objections fall into several buckets:

  1.) Users might pick badly or may re-use nonces when they shouldn't.
  2.) Escaping " is believed to be more secure because it's likely to
break more often, raising developer awareness
  3.) The fix to correct escaping problems is believed to be more reliable

I'm interested in 2 and 3. Users will do dumb things, and both 2 and 3
assumes a similar baseline scenario as 1; a developer did something
dumb. Nonces need not be cryptographically strong for most apps, so
the big problem is re-use. UA's have broad leeway here to prevent
re-use on origins and deny sandboxing to containers that re-use the
same nonces on a single page. They can even help by keeping a list of
recently used nonces and denying reuse.

What concerns me about the " escaping option is that it's harder to
implement by default. Perhaps you see that as a benefit, but if part
of the goal is to raise the average, then allowing markup that can
surround existing DOM structures and secure them easily surely beats
trying to help every web developer understand that stuffing semantic
content into an attribute sausage casing (but don't do it wrong!) is a
good thing.

I'm also looking at this problem from the perspective of ways to help
speed up pages. Iframes have the useful and desirable quality that
they don't load and execute resources synchronously with the parent
document's DOM. For most sorts of ads, widgets, and embedded x-domain
3rd party content, the synchronous nature of mashup content creates
enormous performance problems. Google ads, Facebook Connect badges and
login containers...it's all much slower than it needs to be.

Along with Steve Souders, Adam Barth, and a few others I've been
discussing options for retrofitting content to make an iframe-like
container that participates inline in the current document but which
loads and executes content asynchronously from the perspective of the
main document's content. Getting users to use -- and then secure --
such a container seems to me to be significantly easier sell if the
opening discussion doesn't begin with "first, take your document
fragment and do the moral equiavlent of base64 encoding".

In fact, I'd argue that base64 with a length header might be a simpler
and easier way to handle arbitrary content in attributes. Violations
of the length would make parsing problems even more visible than in
the escaped " case while the default amount of work to do it right
would remain unchanged.

If the security of the system depends on users correctly
pre-processing their content, then I'd like to suggest that we should
be more explicit about it and not accept the "-escaping half measure.
The other option (which I favor) is to not pretend that we can have it
both ways and give users who explictly opt into security features
enough credit to have thought about their use for even a moment.

Regards

On Mon, Jan 25, 2010 at 3:47 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Mon, Jan 25, 2010 at 5:45 PM, Alex Russell <slightlyoff at google.com> wrote:
>> Sorry I'm late to this discussion. Would like to add my objection to
>> using attribute string escaping as a security "feature" in any way. I
>> strongly prefer required nonces attached to opening and closing of
>> sections.
>
> Do you have any suggestions on how to fix the issues that have already
> been raised against that?
>
> ~TJ
>