Bugtraq mailing list archives
Re: Hotmail security hole - injecting JavaScript using <IMG
From: andrew () PIMLOTT NE MEDIAONE NET (Andrew Pimlott)
Date: Fri, 7 Jan 2000 19:49:27 -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
Current thread:
- Re: Hotmail security hole - injecting JavaScript using <IMG Kevin Hecht (Jan 03)
- Re: Hotmail security hole - injecting JavaScript using <IMG Henrik Nordstrom (Jan 04)
- Re: Hotmail security hole - injecting JavaScript using <IMG Metal Hurlant (Jan 05)
- Re: Hotmail security hole - injecting JavaScript using <IMG Ajax (Jan 05)
- Re: Hotmail security hole - injecting JavaScript using <IMG Andrew Pimlott (Jan 07)
- Re: Hotmail security hole - injecting JavaScript using <IMG Eivind Eklund (Jan 08)
- IIS still revealing paths for web directories Vanja Hrustic (Jan 10)
- Re: IIS still revealing paths for web directories Vladimir Dubrovin (Jan 12)
- Re: IIS still revealing paths for web directories Chris Tobkin (Jan 12)
- Altavista Free Internet Security Plex Inphiniti (Jan 14)
- Re: Altavista Free Internet Security Bill (Jan 17)
- Trusted process on an untrusted machine? Mike Frantzen (Jan 18)
- Re: Trusted process on an untrusted machine? Pavel Machek (Jan 19)
- Re: Trusted process on an untrusted machine? Mike Frantzen (Jan 19)
- Re: Trusted process on an untrusted machine? Pavel Machek (Jan 20)
- Re: Hotmail security hole - injecting JavaScript using <IMG Metal Hurlant (Jan 05)
- Re: Hotmail security hole - injecting JavaScript using <IMG Henrik Nordstrom (Jan 04)