Cross Site Scripting holes abound

From: securityat_private
Date: Fri Nov 16 2001 - 18:05:53 PST

  • Next message: Pavel Kankovsky: "Re: OpenSSH & S/Key information leakage"

    
     ('binary' encoding is not supported, stored as-is)
    Mailer: SecurityFocus
    
    :::  Summary  :::: 
    
       Over a year and a half since CERT issued 
    warning on Cross Site Scripting, most dynamic 
    websites are _still_ not filtering user input.  This 
    lets remote sites access to write scripts on vunlerable
    sites, stealing cookies, performing actions on behalf
    of user or modifying look of content on site.  I did a 
    quick 
    check of the top 15 sites (and other sites I use) and 
    found holes in _most_ of them. 
    
    :::  Sites Affected :::
       
       http://www.microsoft.com/
       http://www.msnbc.com/
       http://www.oracle.com/ 
       http://www.about.com/ 
       http://www.doubleclick.net/ 
       http://www.netscape.com/
       http://www.paypal.com/
       http://www.google.com/
       ... many more not listed.... 
    
    :::  Details :::: 
    
       In general, if you can replace any url parameter with
    ""><script>alert(document.cookie)</script>"
     and you get an alert, the site may be vulnerable. 
    
       Samples and details listed at 
      http://www.devitry.com/security.html 
    
        The samples on the above site take it one step 
    futher and send the cookie data to another site.  
    
        Even https sites are vulnerable since cookie data
    is available to javascript on page.
    
    ::::  Fix  ::::: 
    
      You should validate or filter all user input, including
    hidden form fields and id's passed in url's before
    the data is written out to the page.  Any poorly 
    written script on your whole domain could give you 
    problems.  (even old ones that do nothing like 
    testenv)  Filtering or encoding is should be done 
    for  ", >, < and sometimes ' 
    
      You should monitor for "script" passed in url's to 
    your site... However, blocking in the url alone
    is not good enough as the parameter could be passed
    in "POST" data. 
    
      For sites that have your data, you should always 
    log out at the end of your session, and you should
    not surf more then one site at a time. 
    
    :::  Discussion ::: 
    
      Most of these holes were discovered in a matter of 
    minutes.  It takes more time just to find out the owner
    of the site and explain to them why this is a problem. 
    Is there anyway to fix this on a more global basis?  
    
    While these types of holes are not instantly mass
    exploitable, it is good (or bad, depending on how you 
    look at it)  for targeting specify users and sites to 
    steal sessions and personal info. 
    
     -Dave deVitry 
      securityat_private 
    
    ps. microsoft.com exploit url withheld because they 
     think they are safer that way. 
    
    pps. all websites involved were contacted, but most
    had no timely reply.
    



    This archive was generated by hypermail 2b30 : Mon Nov 19 2001 - 10:22:28 PST