Re: Security Test Cases for Testing

["Jeff Williams @ Aspect" <jeff.williams () aspectsecurity com>]

Crispin wrote:

> Detecting XSS is a different process, which I am less familiar with.
> Check out various web application, CGI application, etc. vulnerability
> scanners. Even nessus (a general vulnerability scanner) has some
> capability here. But I'm a curmudgeon, who thinks that XSS issues are
> really client-side issues in the form of browser vulnerabilities (IE's
> lame willingness to execute code) or a problem between the chair and the
> keyboard (IE users :-)

Imagine a web application vulnerable to XSS. There's really no way for a
browser to tell whether a script is a legit part of that site, or something
injected by an attacker.  I'll agree that IE shouldn't allow scripts to
access session cookies, but the web application ain't innocent here. If your
site is accepting scripts in input and sending them back to users, it's
broken.

The simple test for XSS is to find fields that accept input that is later
sent back to users. You'll find them in registration pages, message boards,
transaction forms, error pages, search results, and almost everywhere you
can imagine. We found one in an HTML comment. We even found one in a cookie!
The site sent back an error message that contained the text of the invalid
cookie. Note that if special characters like <>{}&; are translated to their
HTML entity equivalents (like &lt; &amp; and so on) then it's much harder to
inject a script successfully. But you'd be surprised at the different ways
you can encode a script and get it to execute (unicode, hex encode, in a
style tag, and many more -- and note particularly that <> are NOT required.

You'll want to test for both 'stored' and 'reflected' XSS.  Stored XSS flaws
put the input into a database or other storage and send it back to another
user sometime later.  Reflected XSS flaws send the malicious content back to
the user who entered it.  So who cares about reflected, right? Well, it's
trivial to get users to click on links (on the web or in email), and then
they reflect a bad script back to themselves -- where it can disclose the
user's session cookie.

--Jeff

Jeff Williams
Aspect Security
http://www.aspectsecurity.com