[whatwg] The <iframe> element and sandboxing ideas

[Frode Børli]

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