- From: Frode Børli <frode@seria.no>
- Date: Sat, 26 Jul 2008 00:28:36 +0200
> 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(a+5);'... So your sanitizer must also parse CSS properly - including unescaping entities. Notice that if you check for entities in the form of ( remember that Internet Explorer does not require the semi-colon in the end. ( 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.
Received on Friday, 25 July 2008 15:28:36 UTC