+------
 | Update 2004-01-05: You may read _much_ more in my newly published
 | book: "Innocent Code: A Security Wake-up Call for Web Programmers"
 |       http://innocentcode.thathost.com/
 +------




From: "Sverre H. Huseby" <shh@thathost.com>
Subject: Re: CSS, CSS & let me give you some more CSS
Date: Thu, 31 Jan 2002 23:54:27 +0100
To: vuln-dev@securityfocus.com

|   I can't help feel the importance of these cross-site-scripting attacks is
|   over-emphasised.
|   
|   1. You can grab a session cookie which can give you a hijacked login.
|   Obviously not good but also not that easy to implement as it needs quite
|   precise timing.

Not necessarily.  Here are a couple of examples where the timing is
not important:

  * The site in question lets a user store things in a database, that
    will later be sent to other, logged in users (eg. a discussion
    forum).  If output is not correctly "washed", the user will
    receive the script after logging in, so the attacker need not know  
    when the user is logged in.

  * Social engineering 1: An URL with "Check this cool [something] at
    [target site]" in a mail may do.  If the URL contains a script,
    and the target site 1) requires login and 2) routes the victim to
    the original URL after a successful login, the script will be run
    after logging in.  No timing needed.

  * Social engineering 2: A mail with forged sender stating that "we
    suspect that we have a [security/database/whatever] problem.
    Please log in at our site, and go to the following URL to verify
    that everything is OK."  The URL does, of course, contain a
    malicious script.  No timing needed.

|   Also the rightful session owner (even if unsophisticated user) is
|   immediately going to notice something funny is happening when his
|   or her genuine session blows away.

Not if the script is carefully crafted.  The script may redirect the
user to the attacker's site, bringing the cookie with it.  The
attacker's server picks the cookie from the request and stores it in a
database or something.  The only output from the attacker's site is a
new browser redirect that brings the user back to the original site.

I have tried it: No browser flickery or anything that will be noticed
by most users.


Sverre.