An Informational Case Study to Cross Site Scripting Attacks
Nicole Duff and Huiming Yu
Department of Computer Science
North Carolina A&T State University
Abstract
Cross-site scripting attack is one of the most common application layer attacks. It is a topic
taught in computer science curriculum. This tutorial helps students understand what is cross site
scripting attack and how it works. A real world case is presented. Existing prevention approaches
that are used to circumvent the problem are discussed.
1. Introduction
Security is becoming more critical for web applications due to the increase in online usage that
may involve monetary transactions or even sensitive personal identification information.
Hackers or those who chose to exploit vulnerabilities in the web are finding new ways to attack
Web applications. The increasing challenges to secure web applications are due to the Web
applications are developed using many different languages and provide different features to
users. Security within these applications will lower the server performance due to the additional
processing required. That is why these security features may be bypassed when applications are
developed which will increase the vulnerability for application layer attacks.
One of the most common application layer attacks is a Cross Site Scripting (XSS) attack [1, 2, 3,
4, 7]. These attacks are not only used to gain user information, but can also alter the behavior of
the web applications functionality. Along with that it also has the ability to read the web
applications content and post data without the knowledge of a valid user. Cross Site Scripting
attacks can be in the form of error messages that echo the string to the user and in forms filled
out where values are later presented to the user.
2. What Is a Cross Site Scripting Attack
Cross Site Scripting is a range of application-level attacks. It is caused by the failure of an
adequate validation before returning web pages to the client’s browser. Users submit malicious
HTML to dynamic web applications. When other users view the malicious content it appears to
come from a trusted source. The malicious HTML may be embedded inside URL parameters,
forms fields and cookies. Users input that includes malicious code will be executed by the
client’s browser unbeknownst to the user, causing a security attack. This vulnerability is an issue
because of the following [2]:





many web applications are vulnerable,
because no particular application knowledge or skill required; the exploits are simple to carry
out,
Cross site scripting may bypass perimeter security, cryptography, digital signatures, and site
trusting,
developers do not know which element of the web applications allowed the Cross Site
Scripting.
victims do not know which applications allowed this type of attacks.
An example of a typical scenario can involve an attacker that uses a legitimate users privilege to
initiate unauthorized actions. This can cause the legitimate user to become both a victim and an
unknown accomplice to the targeted website. One of the goals for cross site scripting attacks is
to steal cookies from the clients or any other sensitive identifiable information. With this type of
information the attacker can interact with the target site as the legitimate user. A hyperlink can
contain malicious content and the user can be affected when he/she clicks on the link from
another website, instant message, or just reading an email message. This results in a list of
name/value pairs being sent to the server in the form of an http request. Cross site scripting
attack exploits the client side scripts to hijack the user session to another website to redirect the
legitimate user with a malicious hyperlink. Certain processing of web applications, like injection
points to the program which are the ways input is sent to the web server with the GET and POST
http requests, provide the means to a cross site scripting attack. All routines that return data to
the browser such as information to the users and warnings also provide these means. Cookies
are used to associate a unique identifier with a specific user.
In a web application log on two authentication tokens such as a username and password is
exchanged for a cookie. Since those values are stored in a cookie that a user session is
vulnerable if captured by the cross site scripting attack. With this cookie the attacker can load it,
point the browser to the corresponding website, and access the victims account. The extent of
this impact depends on the security features of the web application. For example if there is
cached or saved credit card information this hacker can buy items and may even access bank
records.
This type of vulnerability may be difficult to grasp. So for more clarity an instance can be a
legitimate user using Google search engine for “ HTML Tutorial”. Once in a site called html
help search for the “Tutorial”. The users return URL can look like
http://htmlhelp.com/index.asp?search=Tutorial, but the attacker can create another URL and
make the user to click on it through a link in email or mouse over events on images. That URL
can look almost identical except for the portion that redirects to the hackers site. The fake URL
can
look
like,
http://htmlhelp.com/index.asp?search=</form><form
action=
“hackerdomain.com/hack.asp”>. When the script written in hack.asp is executed that can save
the cookie information.
Cross site scripting attacks can cause very serious damage for Web applications. The following
is a brief list of the potential damage:





hijacking a session from a valid user or unsuspected victim,
manipulating files,
record keystrokes,
using a victim’s computer to attack another system,
and probing a company’s network for more vulnerabilities.
3. Types of Cross-Site Scripting Attacks
There are two types of cross site scripting attacks that are persistent and non-persistent. A
persistent attack stays in the server until accessed by the user. A non-persistent is embedded in
the web page that is returned to the browser following the request.
3.1 Non-Persistent Attack
The non-persistent or Type I cross-site scripting attack is the most common type. The data
provided by a web client are visible and used immediately by server-side scripts to generate a
page of results for that user. Client-side code can be injected into a dynamic page if the user data
is not validated. A classic example is in site search engines: if one searches for a string which
includes some HTML special characters, the search string will be redisplayed on the result page
to indicate what was searched for, or will include the search terms in the text box for easier
editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will
result.
This can be potentially dangerous and become serious because if a user follows a malicious URL
which injects code into the results page, the attacker will have full access to the content. Web
application developers have typically disregarded these vulnerabilities as insignificant [9]. A
detailed scenario is described as follows:
1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to
log in with a username/password pair and store sensitive information.
2. Nicole observes that Bob's website contains a reflected XSS vulnerability.
3. Nicole crafts a URL to exploit the vulnerability, and sends Alice an email, making it look as
if it came from Bob.
4. Alice visits the URL provided by Nicole while logged into Bob's website.
5. The malicious script embedded in the URL executed in Alice's browser, as if it came directly
from Bob's server. The script can be used to email Alice's session cookie to Nicole. Nicole
can use the session cookie to steal sensitive information that is available to Alice
(authentication credentials, billing info, etc) without Alice's knowledge.
3.2 Persistent Cross Site Scripting Attacks
The persistent or Type II cross-site scripting attack is the most powerful attacks. When a user
provides dada to a web application it is first stored persistently on the server like in a database,
file system, or another location, and later displayed to users in a web page without being
encoded. A classic example is with online message boards, where users are allowed to post
HTML formatted messages for other users to read.
This type attack is more significant than non-persistent cross site scripting attack because it can
be rendered more than once. It is potentially dangerous to a large numbers of users. The
methods of injection can vary, and an attacker may not need to use the web application itself to
exploit such vulnerability. Any data received by the web application that can be controlled by an
attacker must be encoded prior to re-display in a dynamic page, otherwise an XSS vulnerability
of this type could result [9]. A detailed scenario is described as follows:
1. Bob hosts a web site which allows users to post messages and other content to the site for
later viewing by other members.
2. Nicole notices that Bob's website is vulnerable to a type II XSS attack.
3. Nicole posts a message, controversial in nature, which may encourage many other users to
view it.
4. Upon merely viewing the posted message, site users' session cookies or other credentials
could be taken and sent to Nicole's web server without their knowledge.
5. Later, Nicole logs in as other site users and posts messages on their behalf....
4. A Real World Cross Site Scripting Attack
In November 2007 a security flaw was discovered in Canada's passport website [8]. It has
allowed easy access to the personal information such as social insurance number, dates of birth,
driver’s license numbers, etc.
A man from Ontario found this flaw after he completed his passport application. He discovered
to alter one character in the Internet address displayed by his Web browser, the information
displayed was other person’s social insurance numbers, driver's license numbers, addresses, and
other forms of identification. Once he saw someone else's information he decided to report this
cross site scripting vulnerability, instead of exploit it.
When Mr. Laning, an IT worker at Algonquin Automotive, informed the passport Canada
website about the cross site scripting vulnerability they suspended the website. The vulnerability
was repaired and Fabien Lengelle, a passport Canada spokesman, said, “This incident is an
isolated anomaly. The online passport system is still a very highly secure application”. After the
website was resumed the vulnerability still existed.
The vulnerability can negatively impact the use of the passport site. The website is supposed to
keep individuals information private, but with a cross site scripting vulnerability it is impossible.
Attackers can hack the website and obtain a lot of personal data on individuals who use this site.
The faith in this website's security is in question, which in turn will cause people not to use it.
5. Prevention Approaches
It is very complicated to establish a comprehensive security solution for cross site scripting
attacks due to the following reasons:





Simple filtering of tags would not help provide protection because there are many tags that
are allowed for formatting the text in web applications.
Coding issues arise because the techniques and vulnerabilities vary and there is not a single
method available to fix all problems.
Hackers develop new evasive mechanisms on a daily basis.
Web application developers improve content with no regards to security measures to help
increase the number of users.
Automated tools can be used to find the entry points to the vulnerable web pages.
There are several proposed solutions and preventive techniques. Some features that a user can
control would be to disable scripting languages in the browser and avoid promiscuous browsing
on untrustworthy websites. Some of features is to validate the input received by a page, and
encrypt, or filter the output returned to the user. This will take the burden away from the user to
make additional steps to ensure security.
The client side solutions proposed by earlier researchers have the following limitations:



These techniques have been proven that are not reliable.
New patches introduced at a central server can not protect the user immediately because it
needs to update the client system.
The Center of Internet Security Enterprise (CERT) states that none of these can prevent
vulnerabilities completely.
The server side solutions provided by researchers in the past have the following limitations:



The solution to a new threat needs to be developed and incorporated into all existing web
pages.
As new web pages are introduced the security features also need to be incorporated at the
web page level.
Every single entry point should be known to implement the security features.
None of these past solutions are equipped to handle the latest developments and would fail if tags
are permitted in the web applications. In the following sections current solutions that are based
on more recently research results are described.
Prevention Approach 1
David Scott et al proposed a solution that involves in defining the security policies for input
validation [3]. This system consists of three major components that are a security policy
description language (SPDL), a policy compiler and an application-level security gateway. A
user can use the security policy description language to describe the validation constraints and
transformation rules. The policy compiler translates the SPDL specification into code for
automatically validate constrains. The application-level gateway can run on the server or
integrate into the server.
This approach provides immediate assurance of security, but it requires the correct identification
and validation policy for each entry point of the application. It would be a difficult task because
it requires very careful configuration by a technical expert. Also the server performance is
adversely affected if the hits increase.
Prevention Approach 2
J. Shanmugam and M. Ponnavaikko developed a signature based model on the server side [5].
This Signature based misuse detection approach introduces a security layer on top of the web
application. It consists of a Blocker, Parser, Verifier and Tag Cluster. The Blocker checks for the
special character in the input. If the Blocker finds one it forwards the request to the Parser. The
Parser splits the request into tokens. The tokens are sent to the Verifier. The verifier checks its
vulnerability, If it is vulnerable returns Yes to the Blocker and redirect the request to an error
page, otherwise returns No to the Blocker and redirect the request to the Web page.
Using signature based model takes advantage of blocking known signatures to reduce the false
positives. It is very effective on social networking sites, such as Facebook and MySpace, email
web applications, and other sites where many web pages are dynamic and are aimed at a mass
user base. This solution overcomes the limitations that previous server side solutions. It has the
following features:



Configurable black listed tags, its attributes, and object implementation procedure for misuse
detection at the server side. Therefore, it does not need to modify existing web pages for new
threats.
The security is separated from the web page implementation, so it does not need to update
new web pages because it is placed at the top most layer of a web application.
Knowledge of entry points are not needed because there is a clear demarcation between the
web application and the security.
Prevention Approach 3
The Service Oriented Architecture (SOA) solution is proposed by J, Shanmugam and M.
Ponnavaikko [6]. It aims to provide independent services that can perform tasks without having
prior knowledge of the calling application. SOA is loosely defined as coupled software services
to support requirements of business processes and software users. This is independent of the
underlying platform and programming language. It involves generating an XML document based
on all form controls submitting by the user. The document will be validated against a schema at
server side. Any malicious script will end up creating an invalid or not-well-formed XML and
stops the user from submitting malicious scripts.
The SOA approach has the following advantages:



The core part of the Cross Site Scripting blocker is platform independent and languages
independent.
Configuration is minimal and can be easily implemented in existing applications.
It is modularized and is constructed based on the proven regular expression patterns.
7. Conclusion
Cross site scripting attack is a serious threat for web applications. Securing Web applications by
using traditional safeguard that are external to the application may be ineffective. A web
developer should adopt secure programming practices by creating an intrinsically secure web
application to preserve its invulnerability as the execution environment changes. A secure web
application should always validate external input because it may carry cross site scripting
attacks. Researchers have proposed different prevention approaches to prevent cross site
scripting attacks. This case study provides the educational material to instructors who teach
security courses and students who study security issues.
References
[1] Kirda, E., Kruegel, C., Vigna, G. and Jovanovic, N., “Noxes: A Client-Side Solution for
Mitigating Cross-Site Scripting Attacks”, In Proceedings of 21st ACM Symposium on Applied
Computing (SAC 2006), Pages: 330 - 337, April 23-27, 2006.
[2] Lucca, G.A., Fasolino, A. R., Mastoianni, M. and Tramontana, P., “Identifying Cross Site
Scripting Vulnerabilities in Web Applications”, In Proceeding of the Sixth IEEE International
Workshop on Web Site Evolution(WSE'04), Pages:71-80, 2004.
[3] Scott, D. and Sharp, R., “Abstracting Application-Level Web Security”, In Proceedings of
11th International Conference World Wide Web, May 2002.
[4] Shanmugam, J. and Ponnavaikko, M., “Behavior-based Anomaly Detection on the Server
Side to Reduce the Effectiveness of Cross Site Scripting Vulnerabilities”, In proceedings of 3rd
International Conference on Semantics, Knowledge, and Grid, Pages: 350-353, Oct 29-31 2007.
[5] Shanmugam, J. and Ponnavaikko, M., “Risk Mitigation for Cross Site Scripting Attacks
Using Signature Based Model on the Server Side”, In Proceedings of 2nd International MultiSymposium on Computer and Computational Science (IMSCCS 2007), Pages: 398-405, Aug.
13-15 2007.
[6] Shanmugam, J. and Ponnavaikko, M., “A Solution to Block Cross Site Scripting
Vulnerabilities Based on Service Oriented Architecture”, In Proceedings of 6th IEEE/ACIS
International Conference on Computer and Information Science (ICIS 2007), Pages: 861-866,
July 11-13 2007.
[7] Su, Z. and Wassermann, G., “The Essence of Command Injection Attacks in Web
Applications”, In Proceeding of the 33rd ACM SIGPLAN-SIGACT Symposium on Principles of
Programming Languages, Pages: 372 - 382, Jan 11-13, 2006.
[8]
Wallace,
K.,
“Passport
Applicant
Finds
Massive
Privacy
Breach”,
http://www.infosecnews.org/hypermail/0712/14063.html
[9]
Wikipedia.
Cross-site
Scripting.
Retrieved
November
2009
from
http://en.wikipedia.org/wiki/Cross-site_scripting