Re: Hotmail security hole - injecting JavaScript using <IMG

[andrew () PIMLOTT NE MEDIAONE NET (Andrew Pimlott)]

On Wed, Jan 05, 2000 at 10:59:52PM -0500, Ajax wrote:
> On Wed, 5 Jan 2000, Metal Hurlant wrote:
>
> > Things are a bit more complicated than that:
> > - javascript code can be placed in a growing number of optional tag
> > parameters (like onmouseover, onload, etc..). The only way to block
> > those is to keep an extensive and up-to-date list of every possible
> > parameter allowing to run a script.
>
> Javascript might not have been a good idea in terms of security.  Price
> you pay for functionality, I suppose.  But since we're stuck with it, if
> one wishes to provide content (in the form of web pages) and expect the
> user to trust it, one must make sure that the content is appropriately
> and reliably sanitized.

Effectively, arbitrary HTML (as implemented by popular browsers) is
arbitrary code.  (Browser war participants should be ashamed of this.)

So what do you do when you have to run untrusted code?  The answer is
well known.  Either,

- Restrict it to a known-good subset of arbitrary code.  This is
  probably unacceptable to services like HotMail, because they don't
  want complaints that, "my friend sent me email with the <superfoo>
  tag, and I can't read it".

or

- Lower the privilege level of the code.  To wit, the <blockscript> tag,
  which effectively lowers the privelege level to writing to the browser
  window.  But evidently, this thought never occurred to browser
  writers, so there's no way to do it.

or

- Don't run it.  Default to displaying HTML email as text.  Tell
  customers that email is a text-based medium for good reasons.  Less
  likely than method one.

The wrong answer is just as well known:  Attempt to detect and remove
bad code.  But by process of elimination, that's what we're stuck with.

To permit a real solution, HTML (as implemented by popular browsers)
must be reformed either to permit reliably separating code from content;
or to permit reliably dropping privileges.  At least the second is
plausible to me, because it requires adding features, not removing them.

(Broken filtering will still be required for old browsers.)

Andrew