2015 INTERNATIONAL CONFERENCE ON COMPUTATION OF POWER, ENERGY, INFORMATION AND COMMUNICATION

A study on removal techniques of Cross-Site

Scripting from web applications

Dr. G. Shanmugasundaram
Associate Professor, Department of Information Technology
Sri Manakula Vinayagar Engineering College
Puducherry, India
P. Thangavellu

S.Ravivarman

B.Tech.,Department of Information Technology

M.Tech.,Department of Networking

Sri ManakulaVinayagar Engineering College

Puducherry, India

Sri ManakulaVinayagar Engineering College

Puducherry, India

Abstract-Cross site scripting (XSS) vulnerability is among

the top 10 web application vulnerabilities based on survey by
Open Web Applications Security Project of 2013 [9]. The XSS
'
attack ocurs when web based application takes input from
users through web pages without validating them. An attacker
or hacker uses this to insert malicious scripts in web pages
through such inputs.. So, the scripts can perform malicious
actions when a client visits the vulnerable web pages. This
study concentrates on various security measures for removal of
XSS from web applications (say defensive coding technique)
and their issues of defensive technique based on that measures
is reported in this paper.

Cross site scnptmg (XSS) is a vulnerable attack that

shall happen in any part of the web application, if that web
application accepts input from an attacker to result in output
without validating the input. The attacker will deploy the
vulnerable scripts at the client system to pass code from a
web page by changing the HTML coding. This usually
eradicates the trust of a client web browser to the websites.
During XSS, the client trusts that the page being displayed
in their web browser was actual page by the website to be
shown.
Of total web applications tested in 2013 where found
25% of vulnerability to be cross site scripting.

Keywords- cross site scripting; vulnerabilities; defensive

coding technique; scripting languages; data validation; data
sanitization; output escaping
I. INTRODUCTION

OWASP 13 has reported XSS as one of the common

vulnerability among web application security threats. This
type of injection vulnerability allows attackers to send
malicious scripts to web browsers and arises when a web
application states user inputs in its HTML pages without
validating them. An attacker inserts vulnerable scripting
codes by those inputs in the HTML pages. When a user
linked to a vulnerable page, the user's browser doesn't know
the existence of malicious codes which may execute all the
scripts forwarded by the web application those results a
successful XSS vulnerability attack. The vulnerable
scripting code of client side scripts might be a JavaScript or
VBScript that can be interpreted by web browsers. XSS
attacks involves various security flaws such as account
hijacking, data theft, cookie theft and poisoning, web
content manipulation, and denial of service. Even by the
practices of using defensive coding approach and
vulnerability detection methods by developers and security
auditors, XSS vulnerability still remains in many web based
applications. A brief study of Cross-site Scripting is given in
the next chapter.

Fig I: 2011 vs 2012 vs 2013 Web vulnerability trends [I6]

XSS provides a gateway for the hacker or an attacker to

deface web sites, deploy phishing attacks, access the web
server's database and can take over a user's web browser
remotely and force the user to continue with option that they
are not known before. Basically XSS vulnerability attacks
are performed as of JavaScript, even any active code can be
used as a potential threat.
A vulnerable part in a web page based on XSS:

II. CROSS SITE SCRIPTING

A.Brief of cross site scripting

978-1-4673-6524-6115/$ 31.00 2015 IEEE

0436

SHANMUGASUNDARAM et al: A STUDY ON REMOVAL TECHNIQUES OF CROSS-SITE SCRIPTING FROM WEB APPLICA nONS

<SCRIPT>varpos=document. URL.indexOf("userna
me=")+5;document.write(document.URL.substring(
pos,document.URL.length));
</SCRIPT>
Welcome you all !

1 <%Stringempidno=request.getParameter("empidno"); %>
2 ...
3
4Employee IDNO:

</HTML>
This JSP code gets an employee IDNO: empidno, by
sending a HTTP request through a browser and outputs
them. XSS are not done in a single way, there are three
ways to imply of XSS are continued further in the next part.

XSS attack leads to many possibilities to intrude the system;

some of the intrusion tasks which are achieved after XSS
attack are mentioned in the next section.

Ill. TYPES OF CROSS SITE SCRIPTING

IV. SUCCESSFUL XSSV RESULTS IN

A. Non-Persistent cross site scripting

As a result of XSS attack the attacker may perform the

following malicious actions:

The Reflected type of XSS is which that passes the

vulnerable codes in the victim's web browser and executes
the codes directly. This attack is possible by an external
source which may be an e-mail or malicious link to
attacker's website.

1)
2)

For example:
http://portal.example/index.php?sessionid=12312312&usern
ame=<script>document.location='http://attackerhost.exampl
e/cgi-bin/cookiesteal.cgi?'+document.cookie</script>

3)

The attacker obtains access to confidential

information's by stealing the account.
Confidential data in the web browsing history and
temp internet files of the web browsers can be
obtained from clients system by spreading web
wonns.
After obtaining the control to the victim's system,
hackers can get through and use the intranet based
web applications.

B. Persistent cross site scripting

Stored based type of XSS vulnerability attack passes the

untreated data which has been given as user input and stored
in the database. This data might be a comment of scripts,
server log file, message queries. Later executes malicious
script from the victim server to the client web browser
without being validated or escaped.

V. AVOIDING CROSS SITE SCRIPTING

A. Data Validation

Data validation is the process of ensuring that your

application is rwming with valid data. The PHP scripting
language based web applications awaits an integer for user
input, if so other types of data get eliminated [7]. Each
source of user data should be processed while receiving for
ensuring it as validate data type and eliminated if it fails the
validation process.For example, in validating a contact
number it should eliminate any strings that have letters as a
contact phone number must consist of numbers only. You
should also take the length of the string into consideration.
And consider the length of a phone number and suitable
special characters that are included to your area
locale.Checking the scripted inputs and encoded forms and
validating them properly leads a website to be free from
XSS vulnerability. The incoming input might be a user
initiated data or some other data.

For example:
<SCRIPT>document.location='http://attackerhost.example/c
gibinicookiesteal.cgi?'+document.cookie</SCRIPT>
C. DOM Based cross site scripting

Document Object Model (DOM) defined by W3C

specification for denoting for XML and HTML standards
and structures. DOM based type of XSS attack is executed
for modifying the DOM script in the victim's web browser
using of current client-side script by user supplied data.
DOM based XSS is mainly functions on JavaScript on the
web browser and allows hacker to use the data obtained by
the script for hijacking user accounts.

Steps required in using untreated input data:

For example:

1)

Standardize:

URL/UTF-7IUnicode/USASCIIIetc

decode the incoming data.

<HTML>
<TITLE>Welcome ... </TITLE>Hello

2)

Character-set checking: Make sure of data that only

has valid characters.

978-1-4673-6524-6115/$ 31.00 2015 IEEE

0437

2015 INTERNATIONAL CONFERENCE ON COMPUTATION OF POWER, ENERGY, INFORMATION AND COMMUNICATION

3)

Length restrictions (minimax): Make sure that the

data occurs within a limit range in number of bytes.

4)

Data format: Make sure that the structure of the

data is reliable with what is expected.

B. Data Sanitization

Data sanitization views on modulating the data for

making sure that it exists in normal form even when
removal unnecessary data in it. For example, for a plain type
of text input from a user it must remove any tags present in
it.

Fig . 2: Sample JSP based vulnerable page[l]

HTML contexts
referenced:

c. Output Escaping

Output encoding or escaping is the process of converting

the data characters that have special meanings to a client
script interpreter into the representations so the special type
of this are eliminated. The data should be treated as data
from other representations, so it must be escaped before
proceeding in the web browser. Escaping all input data
which are untreated before acceptance in the web browser.

inputs

are

usually

HTML attribute (line 9)

2)

JavaScript (line 2)

3)

Cascading style sheets or CSS (line 5)

4)

URL parameter(line 8)

5)

Line 4 which has untrusted link as source which

can result to malicious links by clicking the image
link.

The
propose
XSSVs
consists

fmalStringBuffernewbuf new StringBufferO;

final char[] chars data.toCharArrayO;
for (inti 0; i<chars.length; i++)

user

1)

Example code for JSP on output escaping:

Public static String encode (String data)

where

existing papers based on this defensive approach

an automated approach that statically removes
from program source code. The existing method
of two phases:

A. XSSV Detection

This identifiespotential XSSV's in the program source

code using static analysis.

newbuf.append("&#").append((int) chars[i]);

B. XSSV Removal

returnnewbuf.toStringO;

This phase first determines the context of each user input

referenced in the identified potential XSSVs.
Securing the XSSVs applies the appropriate escaping
methods by using an escaping rules sheet provided by
ESAPI (Enterprise Security API). And uses escaping and
validations process to make the code free from XSS attacks.

From above discussed security measure which prevents

cross site scripting vulnerability based attacks are combined
to give a new prevention method called defensive coding
technique, the defensive coding technique is discussed
briefly in the next section.

A tool developed called saferXSS to automate the

proposed approach for the web applications written in Java
language due to the frequent occurrences of XSS issues in
Java-based web applications.[l]

VI. DEFENSIVE CODING APPROACH

The Defensive Coding approach prevents XSSVs by

escaping all the user inputs used in HTML web pages
according to the contexts in which these inputs are
referenced. Like JavaScript context for input used in a
JavaScript code; HTML element context for input used in an
HTML element.
This practices includes the above
mentioned security measures together to eliminate the
vulnerability completely from web applications.

VII. ASPECT ORIENTED PROGRAMING

Aspect oriented programing is an approach in which the

security aspects are coined and the coding is done or
changed according to those aspects. Aspect oriented
programming is done in three steps. First web application is
analyzed using static analyzing tools (SCA). Next the
security aspects are generated according to the report
delivered by the SCA. Finally AspectShield is designed to
fix those security threats. Aspect Oriented programming is a
prevention mechanism for XSS Vulnerabilities and not
capable for detecting those vulnerabilities. Since exceptional
case are not addressed by this methodology.

JSP based vulnerable web page example:

A. XSSV Detection

978-1-4673-6524-6115/$ 3l.00 2015 IEEE

0438

SHANMUGASUNDARAM et al: A STUDY ON REMOVAL TECHNIQUES OF CROSS-SITE SCRIPTING FROM WEB APPLICA nONS

approach uses those defences that are implemented

in securing vulnerable web applications. It
introduces control flow graph denotation, called
tainted-infonnation flow graph, to audit the
adequacy of XSS defence artefacts. The author
evaluated the proposed method based on the
experiments on seven Java-based web applications.

This phase fIrst determines the context of the web

application by perfonning Static code analysis. The security
cracks in the applications are detected and the security
measures are declared accordingly.
B. Generating security aspects

This phase involves the declaration and the framing of

the rule sets for the security measures need to be taken are
discussed.

3)

C. Building AspectShield

Java aspectj extension is used to implement the defIned

rules into the action and such an example is AspectShield
discussed
by
Bojan
Simic
and
James
Walden.[3]Aspectshield application discussed above will
help the developer in auditing and fIxing the XSSV's in the
application. In the next chapter the prevention mechanism
for the common users and tools that helps the hackers to
fmd the vulnerable websites at the browser end are
discussed.
VIII. RELATED WORKS

Some of existing schemes for automated removal and

other related vulnerability removal techniques are discussed
briefly in the following sub-section.

B. Sanitization

1)

A. Defensive Coding Approach

1)

2)

Bojan Simic and James Walden, [3] proposed an

approach to mitigate SQL injection and Cross-Site
Scripting (XSS) vulnerabilities in java based web
application. By analyzing code using SCA and
removing the defects using Aspect shield which is
based on aspectJava. The code analyzer easily
detects weakness in code and the code can
automatically validated using aspect shield. The
aspect shield tool which performs code validation
for the defected codes in the java based web
application programs. The aspect shield simplifIes
the manual code analyzing by means of Fortify
Source code analyzer tool to identify the vulnerable
codes that are context in the XSS flaws. The author
evaluated the proposed method based on the
experiments on five Java-based web applications.

Lwin Khin Shar, Hee Beng Kuan Tan, [1]

proposed
an
automated
removal
tool
for
eliminating cross site scripting vulnerability from
web applications. The tool initially track the flow
of user inputs into HTML output statements and
identify potentially vulnerable statement along with
control flow graph to detect vulnerable section in
the code and uses pattern matching and data
dependency analysis to identify the HTML
contexts in which the user inputs are referenced
and the required escaping mechanisms that prevent
code injection. It performs source code generation
and replacement to secure potentially vulnerable
statements with proper escaping APIs using
saferXSS[I] tool that was developed by them. The
tool states the vulnerable statements that are
detected as XSS flaws and the statements that are
changed in the code. The author evaluated the
proposed method based on the experiments on fIve
Java-based web applications. Securing the XSSVs
applies the appropriate escaping methods by using
an escaping rules sheet provided by ESAPI
(Enterprise Security API).[26] And uses escaping
and validations process to make the code free from
XSS attacks.

Pankaj Sharma, Rahul Johari, S. S. Sarma,[4]

proposed an integrated model to prevent SQL
injection attacks and reflected cross site scripting
attack (Reflected XSS) in PHP based applications.
This is an effective method to avoid SQL injection
attack and Reflected XSS attack in development of
web application environment. The proposed
mechanism is divided into safe mode and
production mode. Safe mode constructs a security
query model for SQL injection and sanitizer model
for Reflected XSS attack for each identified SQL
queries for SQL injection attacks and input entry
points for Reflected XSS. The development part
has input areas that caries dynamic SQL queries
are validated against security query model
generated in safe mode and normal input text
entered by the user is validated by sanitizer model
instrumented in the code at safe mode.

C. Client Side Detection

1)

Shar, L.K., Tan, H.B.K., [2] proposed a code

auditing approach that recovers the defence model
implemented in program source code and suggests
guidelines for checking the adequacy of recovered
model for XSS attacks. In the implementation
patterns of defensive coding methods, this

Fangqi Sun, Liang Xu, Zhendong Su, [5] proposed

an approach for the client-side scripting solution to
detect XSS wonns. The XSS worm spreads from
one user to another by reconstructing and
propagating its payload. This approach prevents the
propagation of XSS worms by monitoring outgoing
requests that send self-replicating payloads. Also
intercepts all HTTP requests on the client side and
compare them with currently embedded scripts.
The author has implemented a cross-platform
Firefox extension that is able to detect all existing
self-replicating XSS wonns that propagate on the
client side. And the approach results in no false
positive in client side environment. The proposed

978-1-4673-6524-6115/$ 31.00 2015 IEEE

0439

2015 INTERNATIONAL CONFERENCE ON COMPUTATION OF POWER, ENERGY, INFORMATION AND COMMUNICATION

works discussed above is all meant to mitigate XSS

vulnerabilities in java based web applications but
most of the applications of websites being
developed of HTML, ASPX, and PHP. This web
developing platforms also used to develop Social
networks, E-Commerce applications that to be
much secured thus it consists of user credentials
and databases.

NonPersistent

Lwin Khin Shar, Hee

Beng Kuan Tan[l]
L.K.,
Tan,
Shar,
H.B.K.[2]
Bojan Simic and
James Walden[3]
Pankaj
Sharma,
Rahul Johari, S. S.
Sarma[4]
Fangqi Sun, Liang
Xu, Zhendong Su[5]

XSS Type Addressed

Stored

DOM

,(

,(

,(

./

,(

./

,(

,(

XSSer performs the pen test with reference to the

XSS valid vector dictionary recommended by the
OWASP.

XSSer does the tasks like operation testing,

documentation, bug fixing and diffusion of the web
applications. [22]

Fiddler

TABLE I. COMPARISON OF RESEARCH WORKS BASED ON XSS PREVENTION

Existing Research
Contributions

Fiddler is a language neutral application which is

windows oriented .exe file operates on the
windows browser Internet Explorer monitoring
web applications.

Fiddler checks for the malicious scripts if detected

escapes the execution of the code using sandbox.

Fiddler analyzes the proxy server applications that

tacks our http(s) traffics and the internet log files
and debug those configurations. [23]

Fiddler address the issue of cookie stealing, session

tracking comes with XSS. Fiddler is not a complete
remedy for preventing cross site scripting.

Web App/ications

Java
Java
Java
PHP

Java

Enableloopbackutility

IX. BROWSER BASED TOOLS AND METHODOLOGIES FOR

XSSV'S DETECTION

Enableloopbackutility is a windows oriented

application comes as .exe file. It addresses the XSS
vulnerabilities by escaping and redirecting
mechanism.

Enableloopbackutility is developed to operate at

the client side thereby address only client side XSS
scripting and DOM based XSS vulnerabilities.

Another flaw in this application is it is not

distributed so applying it in enterprise level is
merely not possible.

A. Tools
Apache Patches

Apache patches l.3.12 and above provides the

prevention mechanism for XSS by mitigating the
XSSV using proxy modules at the browser level. It
will check for the possible vulnerabilities in the
web page and report it to the user. [21]

Apache patches provide more options for the

general users than the developers.

Apache patches address DOM based XSS

vulnerabilities alone but failed to discuss the other
types of vulnerabilities since it concentrated on the
client side scripting rather than the server side
scripting.

Ra2 DOM based XSS scanner

Another flaw in the Apache patches are they are

designed to work on the standalone systems
configuring this patches in an interconnected
complex environment is complicated nearly
impossible.

Ra2 is a Blackbox scan tool for DOM-Based

XSSV's in the web applications as it works as an
Add-on in Mozilla Firefox.

This Add-on works as a session aware tool which

scans the web applications which requires
authentication. The vulnerable URL's of web
applications are stored in the Database of the tool
and executed locally at the browser.[25]

This tool supports UNICODE character encoding

for avoiding information leakage from the web
applications. [25]

This tool uses native interpreter to handle scripts

based on Java

XSSer

XSSeris an open source package provided for the

Ubuntu and debian environment written in python
under the license version v.3.

B. Methodologies proposed to overcome XSSV

XSSer works as an additional payload for tor proxy

server. It monitors multiple injections that are
embedded with the URL and encode those
injections as Hexadecimal characters to bypass the
XSS vulnerabilities.[22]

Runtime Enforcement ojWeb Browsers

Runtime
Enforcement
ofWeb
Browsers
is
mechanism provided by the Mozilla interprets the
web applications before execution and preform

978-1-4673-6524-6115/$ 3l.00 2015 IEEE

0440

SHANMUGASUNDARAM et al: A STUDY ON REMOVAL TECHNIQUES OF CROSS-SITE SCRIPTING FROM WEB APPLICA nONS

checks for the JavaScript operations as an intrusion

detection mechanism.[19]

The JavaScript intrusion detects Scripts provide by

untrusted source which cause a situations where
abuse of browser resources takes place.

This approach is only applicable to Java Scripts

based on XSS attacks. Further improvements have
not been taken yet to address intrusion mechanism
for different interpreters such as Java, Flash, etc.

DISCUSSION
Drawbacks of existing techniques

XSS vulnerability still exists in most web applications

because of

Browser-Enforced Embedded policies

This method uses a whitelisted scripts and a

sandbox environment that restricts the scripts to
execute on the local hosts and isolate the browser
resources by placing the sandboxes over the
browser.

Usability of tool

DOM

SaferXSS

,(

./

Aspect
Shield
Apache
Patches

,(

./

,(

XSSer

,(

Fiddler

,(

Enable
loopback
utility
Ra2 DOM
Scanner

./

,(

./

./

Developer
side
./

Client
side

./

./

./

./

./

./

3)

The lack of understanding of XSS problem.

4)

The output encoding ends with human error as it

can't escape all untreated data.

1)

Only for reflected & persistent XSS type of attacks

and not for DOM-based XSS

2)

Tool developed based on Java based Web

Applications only and HTML, PHP based web
applications are not issued.

3)

Only server side scripts can be analyzed

4)

DOM based requires client-side scripts as this

system implies only server side scripts.

In this work, we presented a study on various

eliminating
methods
for
the
cross-site
scripting
vulnerability, which plays a vital role in defacement of web
applications majorly. The existing papers analyzed here
defines an idea to approach further using this three security
measures together for eradication of XSSV's in web
application for some limit. The limitations defined might
not affect the existing system much as they lead to future
work to propose a new system of concepts in mitigating the
XSS with all other web application languages and in both
client and server side. The study states current exposes on
removal measures of XSS which can be further extended
and analyzed.

TABLE II. COMPARISON OF VARIOUS XSSV'S TOOLS

Stored

The inadequate implementation of these methods,

CONCLUSION

Though these patches and extensions for browsers are

defined to prevent or blocks script from running on the
web browsers, they doesn't include any security
measures for the developers to build web applications
and only can identify unexpected scripts which are
excluded during encoding code. The summary given
below initiates the drawbacks of existing techniques
and tools which are mentioned above in the basis of
developer side to prevent web vulnerabilities like
security measures, defensive coding and AspectShield
and SaferXSS.

NonPersistent

2)

These drawbacks of existing systems can be overcome

by considering the developer side prevention of XSS
vulnerabilities from web applications.

The usability and accessibility of the applications

and browsers are affected and restricted by this
approach.[10]

Vulnerability discussed

The difficulty of adopting these methods,

Drawback of existing tools

Browser-Enforced Embedded policies are the

proposal that addresses some analogies for host
based intrusion detection techniques, But not for
the execution in local pc's which detects program
misuse.[20]

TOOL

1)

REFERENCES
[I] LwinKhinShar, HeeBengKuan Tan, "Automated removal of cross site
scripting vulnerabilities in web applications", Information and Software
Technology 54 (2012) p.467-478.

[2]Shar, L.K., Tan, H.B.K., "Auditing the XSS defence features

implemented
in
web
application
programs",Software,
TET
(2012) (Volume: 6 , Issue: 4 ) p.377 - 390
[3] BojanSimic and James Walden, "Eliminating SQL Injection and Cross
Site Scripting Using Aspect Oriented Programming", Engineering Secure
Software and Systems (2013) p.213-228
[4] Pankaj Sharma, Rahul Johari, S. S. Sarma,"Integrated approach to
prevent SQL injection attack and reflected cross site scripting attack",
International Journal of System Assurance Engineering and Management,
2012, Volume 3, Issue 4, p.343-35I
[5] Fangqi Sun, Liang Xu, Zhendong Su, "Client-Side Detection of XSS
Worms by Monitoring Payload Propagation", Computer Security ESORICS (2009), Volume 5789, p.539-554

978-1-4673-6524-6115/$ 31.00 2015 IEEE

044 1

2015 INTERNATIONAL CONFERENCE ON COMPUTATION OF POWER, ENERGY, INFORMATION AND COMMUNICATION

[6]Neo
Kobo,
January
2014,
Client-Side
Attacks.<http://neokobo.blogspot.in /2014_01_05_archive.html>
[7] Security measures, http://www.sitepoint.com/php-security-cross-site
scripting-attacks-xss
[8] OWASP, OWASP Top Ten project 2013. http://www.owasp.org
[9] J.H. Hayes, A.J. Offutt "Input validation analysis and testing",
Empirical Softw.Eng. II (4) (2006) p.493-522
[10] H. Liu, H.B.K. Tan, 'Testing input validation in web applications
through automated model recovery", J. Syst. Softw. 81 (2) (2008) p.222233
[II] H. Liu, H.B.K. Tan, "Covering code behavior on input validation in
functional testing", Inform. Softw. Techno!. 51 (2) (2009) p.546-553
[12]OWASPLAPSE+ Project, http://evalues.es/projects/lapse+/lapse+.html
[13] RIPS, PHP Static Code Analayzer,http://www.php-security.orgl
20I0/05 1241 mops-submission-09-rips-a-static-source-code-analyser-for
vulnerabilities-in-php scripts/index.html#sec8
[14] OWASP, Microsoft FxCop (.Net), Other Source Code Analyzer tools,
<http://msdn.microsoft.com/en-us/libraryIbb429476%28v=vs.80%29.aspx>
[15] OWASP, ORIZON Project, Source Code Analyzer tools,
<https:!/www .owasp. orgiindex.php/Category:OWASP_Orizon_Project>
[16] Cenzic Vulnerability Report, Application Vulnerability Trends 2014,
www.cenzic.com/downloads/Cenzic_Vulnerability_Report_2014.pdf
[17]WebApplication
Security
Introduction,<https:!/www.owasp.orglimages/8/ 83/Webappsec_intro.ppt>
[18] Scott, D., Sharp, R.: Abstracting application-level web security. In:
IIth International Conferenceon the World Wide Web, pp. 396-407(2002).
[19] Hallaraker, 0., Vigna, G.: Detecting Malicious JavaScript Code in
Mozilla. In: 10th IEEE International Conference on Engineering of
Complex Computer Systems (ICECCS 2005)
[20] Jim, T., Swamy, N., Hicks, M.: Defeating Script Injection Attacks
with Browser-Enforced Embedded Policies. International World Wide Web
Conference, 2007
[21] Apache patches. http://httpd.apache.orglinfo/css-security/
[22] source forge - xsser
XSSeUhe_mosquito_2011.pdf

tool

http://xsser.sourceforge.net/xsser/

[23]
Fiddler:
http://www.herdprotect.com/fiddler.exe-344714aI95c63
9143da5a2675b458a3215ela3 75.aspx
[24] Software Informer - Paros: http://paros.software.informer.com/3.2/
[25] ra2-dom-xss-scanner: https:!/code.google.com/p/ra2-dom-xss-scanner/
[26] OSWAP _CROSS_SITE_SCRIPTING: https:!/www.owasp.org/
index.php/XSS_(Cross_Site_Scripting)]revention_Cheat_Sheet#XSS]re
vention Rules

978-1-4673-6524-6115/$ 3l.00 2015 IEEE

0442