daemon@ATHENA.MIT.EDU (Andrew Pimlott)
Tue Jan 11 00:41:13 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000107194927.B11068@pimlott.ne.mediaone.net>
Date: Fri, 7 Jan 2000 19:49:27 -0500
Reply-To: Andrew Pimlott <andrew@PIMLOTT.NE.MEDIAONE.NET>
From: Andrew Pimlott <andrew@PIMLOTT.NE.MEDIAONE.NET>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.BSF.4.03.10001052234480.7426-100000@vxgas.linworth.org>;
from ajax@LINWORTH.ORG on Wed, Jan 05, 2000 at 10:59:52PM -0500
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
