Re: Hotmail security hole - injecting JavaScript using <IMG

From: Andrew Pimlott (andrewat_private)
Date: Fri Jan 07 2000 - 16:49:27 PST

  • Next message: rudi carell: "Altavista followup"

    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
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:27:26 PDT