[whatwg] The <iframe> element and sandboxing ideas
frode at seria.no
Sat Jul 26 00:39:52 PDT 2008
> 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
> 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) -
Anyway: how many hours have you spent developing the sanitizer? The
discussion was not wether it could be done server side or not. Imagine
(which it seems HTML 5 will allow). Should the HTML Purifier be
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
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
+47 406 16 637
+47 216 90 000
+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.
More information about the whatwg