- From: Frode Børli <frode@seria.no>
- Date: Sat, 26 Jul 2008 09:39:52 +0200
> Frode B?rli wrote: >> 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. > The way HTML Purifier handles this is unescaping all entities (hex, dec > and named) before handling HTML. Output text is always in UTF-8 and thus > never has entities. The sanitizer seems very good. I see that your purifier does not allow : in urls (which is an important part of for example Wikipedia urls) - but still it makes it difficult to use javascript: style links. Anyway: how many hours have you spent developing the sanitizer? The discussion was not wether it could be done server side or not. Imagine fetching content from another site using a client side javascript (which it seems HTML 5 will allow). Should the HTML Purifier be implemented in pure javascript as well then - or must the content still do a round trip to the server for sanitasion? >> 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). > > A few problems with this theoretical situation: > 1. Why does the bank need an HTML messaging system? Because the bank wants to be percieved as innovative by its customers? It is not my place to question WHY somebody need a feature. Why is there a manufactorer logo on most cars? It isnt strictly required... > 2. Why is this system on the same domain as the intranet web interface? Content is submitted from the banks public website - but customer support handles the mails in the internal webmail system which may be on the same domain.. > 3. Why do customer support personell have access to the transaction > interface? Better question: is it good that since html-sanitizing cannot be done securely we need more employees? If I contact my account manager he most likely have access to perform tasks on my account, as well as on other customers bank accounts. >> 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? > Well, it's an open-source sanitizer. But that aside, say, I was selling > them a support contract, I would not say "valid for eternity". However, Then we need client side sandboxing. >> Today I would not allow HTML-based messages since I could never be >> sure enough that the sanitizer was perfect. > I encourage you to try out HTML Purifier <http://htmlpurifier.org>. It's > certainly not perfect (we've had a total of two security problems with > the core code (three if you count a Shift_JIS related vulnerability, and > four if you count an XSS vulnerability in a testing script for the > library)), but I hope it certainly approaches it. I really appreciate it and will possibly use it depending on its license. It is a problem (for me) that it cannot use : in its urls. PS: Note that PHP is not perfect, and if you rely on PHP-functions for unescaping etc then a future version of PHP might introduce new bugs. I know from experience... -- Best regards / Med vennlig hilsen Frode B?rli Seria.no Mobile: +47 406 16 637 Company: +47 216 90 000 Fax: +47 216 91 000 Think about the environment. Do not print this e-mail unless you really need to. Tenk milj?. Ikke skriv ut denne e-posten dersom det ikke er n?dvendig.
Received on Saturday, 26 July 2008 00:39:52 UTC