IJCSI International Journal of Computer Science Issues, Vol.

8, Issue 4, No 1, July 2011

ISSN (Online): 1694-0814
www.IJCSI.org 650

Prevention Of Cross-Site Scripting Attacks (XSS) On

Web Applications In The Client Side
S.SHALINI1, S.USHA2
1
Department of Computer and Communication, Sri Sairam Engineering College,
Chennai- 44, Tamilnadu, India.

2
Department of Information Technology, Sri Sairam Engineering College,
Chennai- 44, Tamilnadu, India.

Abstract  Cross Site Scripting (XSS) Attacks are transparently run by the web browser. The malicious
currently the most popular security problems in modern script inherits the user’s rights, authentication, and so
web applications. These Attacks make use of on. XSS represents the majority of web based
vulnerabilities in the code of web-applications, resulting security vulnerabilities
in serious consequences, such as theft of cookies, One reason for the popularity of XSS vulnerabilities
passwords and other personal credentials. Cross-Site is that developers of web-based applications often
scripting (XSS) Attacks occur when accessing have little or no security background. The result is
information in intermediate trusted sites. Client side that poorly developed code, riddled with security
solution acts as a web proxy to mitigate Cross Site flaws, is deployed and made accessible to the whole
Scripting Attacks which manually generated rules to Internet. Currently, XSS attacks are dealt with by
mitigate Cross Site Scripting attempts. Client side solution
fixing the server-side vulnerability, which is usually
the result of improper input validation routines.
effectively protects against information leakage from the
XSS protection can be configured for multiple types
user's environment. Cross Site Scripting (XSS) Attacks
of request and response data – URL query parameters
are easy to execute, but difficult to detect and prevent.
– URL encoded input (“POST data”) – HTTP
This paper provides client-side solution to mitigate cross-
headers – Cookies.
site scripting Attacks. The existing client-side solutions
The possibilities to manipulate HTML documents
degrade the performance of client's system resulting in a displayed by the browser with JavaScript or to
poor web surfing experience. In this project provides a influence the operation of the browser itself are
client side solution that uses a step by step approach to dangerous features if misused. The misuse potential
protect cross site scripting, without degrading much the directly relates to the functions available for a
user's web browsing experience. malicious programmer. Unfortunately JavaScript
provides full access to HTML documents using the
document object model (DOM). A script therefore
Keywords -- Cross Site Scripting; web proxy; can modify at least the document it is residing in
Software Protection; Code Injection Attacks; arbitrarily: it is also possible to completely delete the
Security Policies. document and create a t otally different document.
From an attackers point of view two things are of
special interest: cookies associated to a document and
1. INTRODUCTION access credentials. JavaScript also provides access
possibilities to these information. The cookies
Cross-Site Scripting, commonly known as XSS, is a
associated to a document can be accessed using the
type of attack that gathers malicious information
function call document.cookie and application level
about a u ser; typically in the form of a s pecially
access credentials are often acquired using form
crafted hyperlink that will save the users credentials.
based login. Here the credentials are input into input
Cross-site scripting, or XSS is a web security
fields residing in a form environment. Since the form
vulnerability where the attacker injects malicious
is part of the document a script can access all
client-side script into a web page. When a user visits
information in all fields or can simply modify the
a web page, the script code is downloaded and
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 4, No 1, July 2011
ISSN (Online): 1694-0814
www.IJCSI.org 651

target URL of the form. Then the credentials are sent

to the new target, which is under the control of the
attacker. JavaScript is a powerful tool for developing
rich Web applications. Without client-side execution
of code embedded in HTML and XHTML pages, the
dynamic nature of Web applications like Google
Maps, Try Ruby! and Zoho Office would not be
possible. Unfortunately, any time you add complexity
to a s ystem, you increase the potential for security Fig 1: Overview of XSS Attack
issues -- and adding JavaScript to a Web page is no
exception.
2. TYPES OF CROSS-SITE SCRIPTING
Among the problems introduced by JavaScript are:
To prevent the script code contained in a document
loaded from some Web site accesses documents
 A malicious Web site might employ
loaded from some other Web site, browsers do n ot
JavaScript to make changes to the local
allow access between documents loaded from
system, such as copying or deleting files.
different sites (i.e. cross-site access). Therefore
 A malicious Web site might employ
attackers use other techniques to implement a cr oss-
JavaScript to monitor activity on the local
site attack. In general there are currently three major
system, such as with keystroke logging.
categories of cross-site scripting. Others may be
 A malicious Web site might employ
discovered in the future, however, so don't think this
JavaScript to interact with other Web sites
sort of misuse of Web page vulnerability is
the user has open in other browser windows
necessarily limited to these three types.
or tabs.
The first and second problems in the above list can be
- Reflected Cross-Site Scripting attacks
mitigated by turning the browser into a sort of
"sandbox" that limits the way JavaScript is allowed to - Stored Cross-Site Scripting attacks
behave so that it only works within the browser's
- DOM based Cross-Site Scripting attacks
little world. The third can be limited somewhat as
well, but it is all too easy to get around that limitation
• Reflected XSS: Probably the most common type of
because whether a p articular Web page can interact
cross-site scripting exploit is the reflected exploit. It
with another Web page in a given manner may not be
targets vulnerabilities that occur in some Web sites
something that can be controlled by the software
when data submitted by the client is immediately
employed by the end user. Sometimes, the ability of
processed by the server to generate results that are
one Web site's JavaScript to steal data meant for
then sent back to the browser on the client system.
another Web site can only be limited by the due
An exploit is successful if it can send code to the
diligence of the other Web site's developers.
server that is included in the Web page results sent
The key to defining cross-site scripting is in the fact
back to the browser, and when those results are sent
that vulnerabilities in a given Web site's use of
the code is not encoded using HTML special
dynamic Web design elements may give someone the
character encoding thus being interpreted by the
opportunity to use JavaScript for security
browser rather than being displayed as inert visible
compromises. It's called "cross-site" because it
text.
involves interactions between two separate Web sites
The most common way to make use of this exploit
to achieve its goals. In many cases, however, even
probably involves a link using a malformed URL,
though the exploit involves the use of JavaScript, the
such that a variable passed in a URL to be displayed
Web site that's vulnerable to cross-site scripting
on the page contains malicious code. Something as
exploits does not have to employ JavaScript itself at
simple as another URL used by the server-side code
all. Only in the case of local cross-site scripting
to produce links on the page, or even a user's name to
exploits does the vulnerability have to exist in
be included in the text page so that the user can be
JavaScript sent to the browser by a legitimate Web
greeted by name, can become a vulnerability
site.
employed in a reflected cross-site scripting exploit.
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 4, No 1, July 2011
ISSN (Online): 1694-0814
www.IJCSI.org 652

• Stored XSS: Also known as HTML injection been known. Attacks that do not anticipated by the
attacks, stored cross-site scripting exploits are those signature authors are left unprotected by the scheme.
where some data sent to the server is stored (typically The two main aims of XSS attacks are stealing the
in a database) to be used in the creation of pages that victim user’s sensitive information and invoking
will be served to other users later. This form of cross- malicious acts on the user’s behalf. Noxes provides a
site scripting exploit can affect any visitor to your client-side web proxy to block URL requests by
Web site, if your site is subject to a stored cross-site malicious content using manual and automatic rules.
scripting vulnerability. The classic example of this Reference presents another approach: tracking the
sort of vulnerability is content management software flow of sensitive information in the browser to
such as forums and bulletin boards where users are prevent malicious content from leaking such
allowed to use raw HTML and XHTML to format information. Both of these projects focus on ensuring
their posts. confidentiality of sensitive data (e.g., cookies) by
As with preventing reflected exploits, the key to analyzing the flow of data through the browser, rather
securing your site against stored exploits is ensuring than preventing unauthorized script execution. They
that all submitted data is translated to display entities can defeat only the first goal of XSS attacks. It would
before display so that it will not be interpreted by the be defeated by attacks that do not violate same-origin
browser as code. policies. By contrast, our approach is based on
. analyzing function-call sequences of JavaScript to
• DOM-based XSS: It is a special variant of reflected detect unauthorized scripts; we can defeat both
XSS, where logic errors in legitimate JavaScript and objectives of XSS attacks.
careless usage of client-side data result in XSS One of the most important discussions related to
conditions. aspects of code injection is by CERT. The paper
Application developers and owners need to describes the source of code injection: invalidated
understand DOM Based XSS, as it represents a threat input from untrustworthy sources. It also proposes
to the web application, which has different solutions that may be carried out directly by users.
preconditions. As such, there are many web On the client side, the most effective solution is to
applications on the Internet that are vulnerable to disable all scripting language support in user’s
DOM Based XSS, yet when tested for standard XSS, browsers and e-mail readers. If this is not a feasible
are demonstrated to be “not vulnerable”. Developers option for business reasons, another recommendation
and site maintainers need to familiarize themselves is to use reasonable caution when clicking links in
with techniques to detect DOM Based XSS anonymous e-mails and dubious web pages. Also,
vulnerabilities, as well as with techniques to defend keeping up to date with the latest browser patches
against them. and versions is important. But usually, neither do
users willing to disable all scripting language
support, nor do they keen to keep their browsers up to
3. RELATED WORK date let alone how many of them are aware of the
dangerous XSS.
By now there have been a variety of defensive Scott and Sharp used an application proxy to abstract
techniques to prevent XSS, including the following Web application protection; the proxy validates user
aspects: static analysis, dynamic analysis, black-box input to protect against XSS attacks. Commercial
testing, white-box testing, anomaly detection, etc. products such as Appshield and InterDo use a similar
Generally, these approaches are deployed on the approach. However, even though it provides
client-side or server-side to protect web users from immediate assurance of Web application security, it
XSS injection attack. To remedy the shortcomings of requires the correct identification of and validation
server- side protection, there have been several policy for each individual entry point to a Web
defensive strategies which are deployed on the client application. Another limitation is that this approach
side. In a client-side mechanism for detecting protects Web applications at the deployment phase
malicious JavaScript is proposed. The system instead of trying to eliminate bugs during the
consists of a browser-embedded script auditing development phase. One thing should not be avoided
component, and an IDS that processes the audit logs when discussing the server side solution, the
and compares them to signatures of known malicious performance.
behavior or attacks. With this system, it is possible to Most existing browsers are capable of interpreting
detect various kinds of malicious scripts, not only and executing scripts created in such scripting
XSS attacks. languages as JavaScript, JScript, VBScript that are
However, the system has significant weakness: it can embedded in the Web-page downloads from the Web
only detect the XSS attacks whose behavior haven server. When an attacker introduces a malicious
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 4, No 1, July 2011
ISSN (Online): 1694-0814
www.IJCSI.org 653

script to a dynamic form submitted by the user, a web site. We assume the attacker has the following
cross-site scripting (XSS) attack then occurs. abilities:
• The attacker owns and operates a web site.
4. PROPOSED MODEL • The user visits the attacker's web site.
• The target web site lets the attacker inject an
The solutions on server side result in considerable arbitrary sequence of bytes into the entity-
degradation of web application and are often body of one of its HTTP responses.
unreliable, whereas the client side solutions result in
a poor web browsing experience, there is need of an Vulnerability Coverage. Ideally, a client-side XSS
efficient client side solution which does not degrade would prevent all attacks against all vulnerabilities.
the performance. The proposed system is designed in However, implementation is infeasible. Instead, we
order to provide effective security against the Cross focus our attention on a narrower threat model that
Site Scripting attack, keeping the concept of usable covers a certain class of vulnerabilities. For example,
security with optimized web browsing. This approach we consider only rejected XSS vulnerabilities, where
uses a three step process: the byte sequence chosen by the attacker appears in
the HTTP request that retrieved the resource.

Attacker Goals: We assume the attacker's goal is to

run arbitrary script in the user's browser with the
privileges of the target web site. Typically, an
attacker will run script as a stepping stone to
disrupting the confidentiality or integrity of the user's
session with the target web site. In the limit, the
attacker can always inject script into a web site if the
attacker can induce the user into taking arbitrary
actions. In this paper, we consider attackers who seek
to achieve their goals with zero interaction or a
single-click interaction with the user.

5. IMPLEMENTATION & EXPERIMENTAL

Fig 2: Proposed Solution: a three step process to detect XSS RESULTS

This solution was implemented using open source

Mozilla Firefox 1.5 web browser from Mozilla
foundation.
The Mozilla Firefox web browser executes
JavaScript programs included in web pages with the
help of the JavaScript engine called SpiderMonkey.
The engine, written in C, is an important part of the
web browser. It is used to execute JavaScript
programs included in web pages as well as for the
Gecko rendering engine that is used to display
HTML, CSS, and XUL (Mozilla’s XML-based User
interface language), and run JavaScript programs.
The solution needed some major changes in the
JavaScript engine and some minor changes in other
components of the web browser. Some Data
structures were created, and others were modified
Fig 3: Block Diagram to detect XSS according to the need.

THREAT MODEL 5.1. Security Evaluation

Attacker Abilities. Client-side XSS _lters are The proposed solution has been tested with thousands
designed to mitigate XSS vulnerabilities in web sites of malicious inputs, non vulnerable input with white
without requiring the web site operator to modify the listed tags and vulnerable websites. Fig. 4 shows
comparison of the proposed browser with Firefox
IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 4, No 1, July 2011
ISSN (Online): 1694-0814
www.IJCSI.org 654

without security implemented, Microsoft’s Internet 6. CONCLUSION

Explorer, Apple’s Safari Web Browser and other
available web browsers on same platform and The proposed solution is found to be very effective
environment. It has been observed that there are more by the experimental results. The solution is platform
than 100 variants of XSS attacks exist and the independent so we block suspected attacks by
approach is tested with the data collected from preventing the injected script from being passed to
various research sites, white hat and black hat sites. the JavaScript engine rather than performing risky
transformations on the HTML. Cross-site scripting
attacks are among the most common classes of web
security vulnerabilities. Every browser should
include a client-side XSS to help mitigate unpatched
XSS vulnerabilities. Cross-site scripting is a Web-
based attack technique used to gain information from
a victim machine or leverage other vulnerabilities for
additional attacks. These practices employ policy,
people, and technology countermeasures to protect
Fig 4: Security Evaluation of the proposed web browser against XSS and other Web attacks.
In general, the system successfully prohibits and
5.2. Performance Evaluation removes a variety of XSS attacks, maximizing the
protection of web applications.
The proposed solution has been tested with thousands
of malicious inputs, non vulnerable input with white REFERENCES
listed tags and vulnerable websites. Fig. 5 shows how
the attacker can inject the malicious script code into a [1] Engin Kirda, Christopher Kruegel, Giovanni
trusted website with the help of Control flow graph. Vigna, and Nenad Jovanovic. Noxes: A client-side
This control flow graph intimates to the Client solution for mitigating cross site scripting attacks. In
(Administrator) about when the attacker can hack the Proceedings of the 21st ACM Symposium on
information, what are all the information that can be Applied Computing (SAC), 2006.
hacked. The vast of majority of XSS attacks can be
prevented by identifying the user input locations [2] CERT. Advisory CA-2000-02: malicious HTML
within the web application and ensuring the source tags embedded in client web requests,
code handling these has proper measures in place. <http://www.cert.org/advisories/CA- 2000-02.html>;
From a d eveloper’s perspective, this means ensuring 2000.
all data inputted from a user is properly encoded to
remove HTML and script markup to be replaced with [3] CERT. Understanding malicious content
text that all browsers can process. mitigation for web developers,
<http://www.cert.org/tech_tips/malicious_code_mitig
ation.html>; 2005

[4] D. Scott and R. Sharp. Abstracting Application-

Level Web Security. In Proceedings of the 11th
International World Wide Web Conference May
2002.

[5]Open Web Application Security Project, “The ten

most critical web application security
vulnerabilities”,2007,ww.owasp.org/index.php/OWA
SP_Top_Ten_Project

[6] K. Fernandez and D. Pagkalos. Xssed.com - xss

(cross-site scripting) information and vulnerabile
websites archive. [online], http://xssed.com
Fig 5: Control Flow Graph displays how the attacker can inject (03/20/08).
the code