Mark Curphey mark at curphey.com
Sun Nov 23 14:54:25 EST 2003

Hi Javier, 
Great start. I have a few suggestions / comments that may be considered ?
1. In the first paragraph I think it should be "in the web application" not
the web server. 
2. I think it might be worth highlighting that the problem can occur
anywhere where input is converted into output without be filtered. That
covers TRACE etc as well.
3. I think it is worth listing an HTTP TRACE request as a source
4. It maybe worth listing potential sources  / payloads i.e. any http header
form values
name value pairs in GET requests
POST payloads (HTML forms or otherwise)
Data from Databases and other data sources
6. Might be worth a list of potential targets such as users browsers, html
aware log files, html aware email clients, error messages (which maybe a
source not a target)
7. How about XSS in XML payloads ? Webservices have the same issues I think.
8. The biggest thing I would add would be a section on how to look for XSS
in code. As code review is by far the most effective way to find any
security issue I think it needs to be as prominent as possible. That may
look something like this
A. List and review all of the data entry points to the applications. This
should include user input, data feeds etc
B. Trace each piece of data and determine if it is ever send back to any
user at any point in its life-cycle
C. If it is sent back to a user,  is it filtered ? (note all input should be
filtered anyways as a matter of course)
9. You focus on XSS with cookie stealing but as the WebGoat lesson points
out database data theft etc is equally probable. It may be worth pointing
that out at some point.
Anyways just a few thoughts / comments..great job !


From: Javier Fernandez-Sanguino [mailto:jfernandez at germinus.com] 
Sent: Monday, November 17, 2003 1:00 PM
To: Penny Major
Cc: mark at curphey.com

Title Cross Site Scripting

Date 17th November

Author Javier Fernández-Sanguino

Short Description of Issue

Cross Site Scripting attacks (XSS) are attempts to subvert the relationship
between a user's browser and a trusted site in order to retrieve sensitive
information from the user's browser. Attackers can exploit this attack due
to flaws in the web server code (such as the way error request are shown) or
in the way it stores information that is later on presented to user
(comments to news, forums, web-based e-mail readers, etc.). If the
information is not sanitized before it is stored or  if it is not santized
when introduced into an HTML object, it might lead to code execution in the
users's browser, this code is executed as in the context of the trusted
site. Execution of code, including Javascript, VisualBasic Script,  ActiveX,
or Java applets can be used for a different purposes (including arbitrary
remote code execution in vulnerable or misconfigured browsers), but a Cross
Site Scripting has as its main purpose the retrieval of session information
that involves the remote site. This session information (usually in the form
of cookies) can then be used to hijack the user's session (before it
expires) if the remote site does not control where the session was
established form.

XSS attacks can be produced both by sending crafted URLs to potential
targets through e-mail or by storing them in web-pages and hiding them as
legitimate links, images, or other type of information. Common sources of
these kind of attacks are webmail applications and web-based bulletin
boards, but in some cases even web servers are directly affected.

How to Test

Testing the success of XSS attempts involves determining where does the web
application introduce information generated by an attacker into an HTML
response which might be viewed by a user (and interpreted by his browser).
Usually, determining that JavaScript will be run is enough to demonstrate
that an XSS attack is possible. Although whether or not this kind of attack
can succeed depends on if this attack can be introduced permanently into the
web server (for example through a comment posted in the web site) or needs
to be done through social engineering attacks (like e-mail).

Black Box

In order to do black box testing of XSS the tester first needs to determine
which parts of the web server application introduces information generated
by an attacker. This can include either dynamically generated HTML pages
based on POST or GET calls to applications (including error pages they
generate which include said content) or content generated based on
information stored in the website that is later on presented to legitimate
users. Once these places have been determined the tester should try to
inject code and see if it is included verbatim in the HTML page returned and
whether it is filtered or not. If filtered, the tester needs to make sure
that all potential sources for XSS attacks are appropiately filtered.

Notice that it is also necessary to determine if it is possible to do
session replays (using retrieved cookies) from sources different from the
one that started the session. Session hijacking might be hindered and even
if XSS attacks are possible, their impact might be limited.

White Box 

Source code analysis must be focused on how the application manages
information that is presented to the end user or stored to later generate
HTML pages . Any such information must be sanitized before storage and must
be also santized before it is given to the user; this includes filtering all
HTML tags. If HTML tags are allowed in the content, the reviewer must make
sure that the filter implement to sanitize these tags only allows tags (and
parameters) which are not subject to XSS attacks. 



Sample XSS attack:


More information about the Owasp-testing mailing list