[whatwg] The <iframe> element and sandboxing ideas

Frode Børli frode at seria.no
Fri Jul 25 15:28:36 PDT 2008


> Frode Børli wrote:
>> <td colspan='javascript(a + 5)'></td>
>>
>> Where a javascript returns the value in the colspan attribute. Many
>> server side HTML sanitizers would have to be updated - unless we
>> introduce a proper sandbox.
>
> Or the HTML sanitizer could have done things properly and checked if
> colspan was a numeric value. :-)

Yeah, I thought about that also. Then we have more complex attributes
such as style='font-family: expression&#40;a+5&#41;;'... So your
sanitizer must also parse CSS properly - including unescaping
entities. Notice that if you check for entities in the form of &#40;
remember that Internet Explorer does not require the semi-colon in the
end. &#40 is translated by Internet Explorer but not by the PHP
entity_decode function.

For all I know - a future invention may introduce a new method of
encoding entities also, so your sanitizer must support all future
entity encodings.

Ofcourse we can skip supporting the style attribute - but there are
not many other ways to style content in XHTML.

> Disclaimer: I am one of those authors of server side HTML sanitizers you
> speak of.

Theoretically speaking:

A bank want a HTML-messaging system where the customer can write
HTML-based messages to customer support trough the online banking
system. Customer support personell have access to perform transactions
worth millions of dollars trough the intranet web interface (where
they also receive HTML-based messages from customers).

Security depends on on a perfect sanitizer. Would you sell your
sanitizer to this bank without any disclaimers, and say that your
sanitizer will be valid for eternity and for all browsers that the
bank decides to use internally in the future?

Today I would not allow HTML-based messages since I could never be
sure enough that the sanitizer was perfect.


More information about the whatwg mailing list