[whatwg] some thoughts on sandboxed IFRAMEs

[Michal Zalewski]

> Not escaping " is so easily and quickly discovered that I really don't
> think that's a problem.

The same argument could be made for not escaping <, but I don't think
it's valid in practice - particularly for (hypothetically) constrained
input fields.

>> That would be great. I think Adam proposed we have a separate
>> sandbox="..." toggle for this. Whether it's on or off by default
>> probably doesn't matter much.
> Adam's feedback (not quoted here, but in the same thread as the e-mail to
> which this is a reply) suggests that this is actually a bad idea, so I've
> not changed this.

There are obvious, existing usage cases where sites struggle to
prevent automated resource loading across domains - e.g., almost every
HTML-supporting mail client; so it strikes me that if we go along with
this reasoning because a perfect solution may not exist, we're also
effectively saying that what they are doing should not be attempted at
all (then what's the alternative? one should probably be a part of
HTML5).

> If there's no HTML, there's no need for a sandbox, so the simplest
> solution is just to escape the <s and &s.

Which people fail at, big time. There are 50,000+ entries on
xssed.com, many of them against big sites presumably developed by
skilled developers with the help of sophisticated frameworks -
microsoft.com, google.com, amazon.com, ebay.com, etc. It is a really
low-effort tweak to accommodate it here, and it may offer a very
significant security benefit, so...?

>> Keep in mind that pretty much every web application already needs to
>> safely generate unique, unpredictable tokens - for session identifiers
>> that guard authenticated sessions. If they can't get it right, they are
>> hosed anyway - but problems here are not horribly common, in my
>> experience at least, and web app frameworks do a decent job of helping
>> developers by providing token-generating facilities.
>
> Pretty much the same can be said of escaping text.
>
> Also, based on Adam's comments, it seems that things aren't really as rosy
> as all that for token generators.

I think the difference is huge; in a typical web framework, you need
to explicitly escape every single piece of potentially dangerous
attacker-controlled input to stay safe - and because people tend to do
some validation at input stage, it's very difficult to audit for it.
Escaping also needs to be very different depending on the context
(URLs need to be encoded differently than HTML parameters, and
differently than standalone text).

So even though your framework may provide several escape() functions,
it's very easy to get it wrong, and people constantly do. OTOH, if
your framework provides a get_token() function, there's really not
that much to using it properly.

I'm coming from a background of doing lots of security reviews for
existing applications, so while I appreciate that the difference may
be subtle, the real-world error patterns speak to me pretty strongly;
and I do think that insufficient escaping is drastically more common
than used, but insufficiently unpredictable XSRF tokens.

/mz