[whatwg] some thoughts on sandboxed IFRAMEs

[Kornel Lesinski]

On 4 Feb 2010, at 17:44, Michal Zalewski wrote:
>> 
>> 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...?

The problem comes from lack of escaping of any kind, so change in escaping method will not fix the problem, i.e.,

Hello $unescaped_name

is as vulnerable as:

Hello <iframe sandbox srcdoc="$unescaped_name">

> 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.

That's problem with the frameworks (a big one, admittedly). However, there are templating engines that escape all variables, everywhere, by default, and this solves the problem very well.

Addition of token-based sandbox won't improve anything in cases where authors forget to escape or wrongly assume that input is already filtered/escaped or harmless. If someone forgets to add escape(), why would they remember to add <sandbox>? Additionally <sandbox> will cause new security problem in all current UAs, so for plain text I don't see any benefit at all.

However, if we're going to introduce token-based sandbox anyway, I suggest putting token in tag name:

<sandbox-$token>...</sandbox-$token>

where $token is the random part. This avoids oddity of attributes in closing tag, and is compatible with XML. In XML you could also use:

<$token:sandbox xmlns:$token="…"></$token:sandbox>

-- 
regards, Kornel Lesiński