RE: Cross Site Scripting Vulnerabilities - XSS

["Jeremy Junginger" <jjunginger () interactcommerce com>]

Anyone have tips on remotely viewing ie history files?  Assume that you
already have admin priveleges on the box.  It appears that IE has an
internal mechanism to prevent remote viewing of the Internet History.
I've already grabbed all other pertinent data, but have not yet been
able to view the history.  Any tips would be appreciated.  I tried
taking ownership of the file, but that didn't appear to help much.


-----Original Message-----
From: Jeremiah Grossman [mailto:jeremiah () whitehatsec com] 
Sent: Tuesday, August 06, 2002 1:22 PM
To: Jason binger
Cc: pen-test
Subject: Re: Cross Site Scripting Vulnerabilities - XSS


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/

Attachment: smime.p7s
Description: