From: Jeremiah Grossman (jeremiah@whitehatsec.com)
Date: Tue Aug 06 2002 - 16:22:00 EDT
A procedure for testing for XSS problems is largely variable upon the
implementation and design of the system in question. Testing for XSS in
Web/HTML mail is different from Message Boards, is different from web
server 404 echo testing, its different from CGI input echoing. The
successful execution of script in each instance might be similar, but
the implementation on how this is achieved may be quite different. This
is because the input and output data land if varied places. So
currently, there is no formal procedure that I have some across for
testing XSS effectively. We all rely on our experience.
Now that I have given you no help...let try something different...
The general idea with regard to XSS testing is that you are trying to
input data into a web application which will then execute script when
viewing the output (wherever that may be). The emails before have given
you good feedback on how they do things, so lets give you a few other ideas.
Web Application should never store or worse output "<" and ">"
characters without converting them into their equivalent HTML entities.
If they do, for the sake of ALLOWING HTML (example: WebMail), the web
application must endure the task of separating Client-Side Script from
HTML. Something I have never seen a web application effective perform.
As I have said in the past, if you allow HTML to be output, your
allowing script to hit the client-side (util someone demonstrates
otherwise.)
Upon testing CGI's, here's the proceedure I take. Identify each web
application, docuement every input source, whats its used for and where
the output lands. I then proceed to input the simplest of data strings,
such as "<" or ">" and view the output source to see what the filters
(if any) did. If I am able to get even an innocuous "<U>" tag through to
the output, its a problem that needs to be corrected. Remember, input is
not just limited to input CGI parameters, but also one must consider
HTTP Headers as well or anything a web app may use that originates on
the client-side. Now this might have helped a little.
Lets confuse the situation. There are many techniques that have been
used to bypass filters designed to thwart XSS. You may have heard terms
such as "URL Encoded Strings", "Filter Bypass Manipulation", etc. There
are cheat sheets (like Bill's) many professionals use when testing
security measures that prevent XSS. All these different XSS variants
must be test ed thoroughly, because one hole ruins all the security work.
<img src="&{alert('XSS is a Cockroach')};">
Jeremiah-
Dave Aitel wrote:
> I just use SPIKE Proxy, modify each variable by hand to be something
> with a <, and then look at the result to see if it's messed up. Maybe
> I'll throw in something to SPIKE real quick to generate a browser window
> for each variable fuzzed and then you can quickly tab through them and
> be done with it.
>
> -dave
> "Cross site scripting is a problem that affects us all." - The unix
> terrorist, GOBBLES talk, DefCon 0x0a
>
----------------------------------------------------------------------------
This list is provided by the SecurityFocus Security Intelligence Alert (SIA)
Service. For more information on SecurityFocus' SIA service which
automatically alerts you to the latest security vulnerabilities please see:
https://alerts.securityfocus.com/
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:24 EDT