1
Framework for Detecting and Preventing XSS Attacks
1
OMAR MOHAMMED MAHDI, 2 Mr. SANJAY T. SINGH
Research Scholar, Dept. of Computer Sci. & IT, SHIATS-Allahabad, India, Email:omeralbadi@yahoo.com
2
Assistant Professor, Dept. of Computer Sci. & IT, SHIATS-Allahabad, India. Email:sanjayt.singh@gmail.com
1

Abstract-- Today the users perform most of the work by web
It’s depicts two way flow of information between the server
applications, therefor web applications are popular targets of
and browser. Therefore we must do registration and login to
security attacks and one of the most dangerous attacks it's
XSS. Cross-site scripting involves the insertion of malicious
perform financial transactions, search etc. The information is
private and highly sensitive. Security is therefore a big issue:
code into web pages in order to manipulate website visitors. In
this paper propose a mechanism to detect and prevent XSS
attack. This mechanism is based on a programming intent
no one wants to use a web application if they believe their
information will be disclosed to unauthorized parties. Web
evaluation technique to detect possible XSS Injection attacks by
applications bring with them new and significant security
analyzing the malicious code, compare it with a stored form of
threats. Each application is different and may contain unique
XSS code and delete the hacker if he is a member in the web
vulnerabilities.
site.
developers who have little understanding of the security
Most
applications
are
developed
by
problems that may happen in the source code they are
Index Terms-- XSS – cross site script, web application security,
Java script, and Injection attacks.
I. Introduction
A. Web Application Security:
In the early days of the Internet, the World Wide Web
consisted only of web sites. There were intrinsically
information depots containing static documents, and web
producing
[2].
Today’s
internet
services
and
web
applications have become prime part of daily life, and today
we see more than eight hundred million persons use the web
to transfer money every day and done more than billion
dollars transfer by the webs. Therefor we see web
applications are popular targets of security attacks, and one
of the most dangerous attack its XSS [1].
browsers were invented as a means of retrieving and
displaying those documents from server to browser. Most
sites did not authenticate users, because there was no need to
each user was treated in the same way and presented with
the same information. Any security threats arising from
hosting a web site related largely to vulnerabilities in web
server software (of which there were many). If an attacker
compromised a web server, he would not normally gain
access to any sensitive information, because the information
held on the server was already open to public view. Rather,
An attacker would typically change or modify the files on
the server to distort the web site’s contents form. Most of
sites on the webs are in fact applications.
B. Cross Site Scripting (XSS):
Cross-Site Scripting attacks (XSS attacks for short) are
those attacks against web applications in which an attacker
gets control of the user’s browser in order to execute a
malicious script (usually an HTML/JavaScript4 code) within
the context of trust of the web applications site [9]. Crosssite scripting (XSS) is an attack against web applications in
which scripting code is injected into the output of an
application that is then sent to a user’s web browser. In the
browser, this scripting code is executed and used to transfer
sensitive data to a third party [6]. In Cross-site Scripting
(XSS) attack, an attacker forces a client, typically a web
browser, to execute attacker-supplied executable code,
2
typically JavaScript code, which runs in the context of a
clicks this link then search form gets submitted with
trusted web site [5]. Cross Site Scripting is up till now
JavaScript code as query string, as a result the Script is sent
another type of attack on the web applications. In this
back to the victim, as a part of the web page with result. As
malicious data is injected into a database so as to achieve
soon as this script gets executed, the cookie set by valid site
unauthorized access to connection of an authorized user [8].
will be forwarded to the malicious web site in the form of
Cross-site scripting (XSS) is one of top two vulnerabilities
parameter to the invocation of the steal-<page> server-side
in Web applications. The XSS vulnerabilities are due to
script. This cookie will get saved on the malicious website.
using untrusted data from the Web application as the partial
This can be further manipulated by attacker through
contents of HTML page’s output and this attack may result
impersonating the unsuspecting user in respect to trusted site
in
[4].
information
implementation
disclosure
of
[7].
Furthermore,
HTML interpreters
embedded
the
in
browsers incompletely complies with specifications or
C. Persistent XSS
provide extra functionalities. Web application programmers
This is a type of XSS attack where malicious code is stored
difficultly is to how to sanitize the input message for
persistently in a resource like file system, database or some
preventing the XSS vulnerabilities by uniform XSS patterns
other location which is managed by server and displayed to
or detection rules. In general, an XSS attack can be
the users later. There is even no requirement of encoding as
separated into the attack vector and the attack body [3].
it is sent using html entities. As for example in case of an
online message board users post messages which can be
II. Types of Cross site script code
accessed by others later on some time [4].
XSS attacks are of three types: DOM Based, non-persistent
attacks and persistent attacks.
A. DOM based
This kind of XSS attack is performed by changing the
III. Types of Attacks XSS
There are two general methods for injecting malicious code
into the web page that is displayed to the user.
DOM environment on client side instead of sending the
A. Reflected XSS
malicious code to server. So there is no chance of
The attack script is not persistently stored, but, instead, it is
verification of payload by the server. In this kind of invasion
immediately “reflected” back to the user. For instance,
major browsers are compelled to not to send the malicious
consider a search form that includes the search query into
payload to server. As a result even well-setup XSS filters
the page with the results, but without filtering the query for
become null against such attacks.
scripting code. This vulnerability can be exploited, for
B. Non – persistent XSS
example, by sending to the victim an email with a specially-
This is most common type of XSS vulnerability. The
crafted link that points to the search form and that contains
malicious code is not stored persistently; however it is
the malicious JavaScript code. By tricking the victim into
reflected to the user immediately. As for example, let us
clicking this link, the search form is submitted with the
consider a form for search query which displays results on to
JavaScript code as the query string and the attack script is
the page and the query is not being filtered for any scripting
immediately sent back (reflected) to the victim, as part of the
code. This can be easily exploited by an attacker through
web page with the results. The optimal approach to prevent
sending a victim user an email containing specially designed
XSS attacks would be to eliminate the vulnerabilities in the
link which is pointing to this search form and contains a
affected web applications. To this end, a web application
malicious code in JavaScript. If the victim gets tricked and
must properly validate all input, and in particular, remove
3
malicious scripts. The problem is that many service
document.images[0].src = "http://evilserver/image.jpg?
providers do not fix their web applications in a timely way.
stolencookie=" + document.cookie;
Hence, a promising approach for protecting users against
</script>
XSS attacks is to deploy the necessary security mechanisms
And can we see in figure (2) the mechanism of the stored
on the client side.in the figure (1) we can see the mechanism
technique.
of the reflected technique.
Fig. (2) Sends the user’s cookie to a server under the
Fig. (1) Reflected Technique
B. Stored XSS
The attacker persistently stores the malicious code in a
resource managed by the web application, such as a
database. The actual attack is carried out at a later time,
when the victim requests a dynamic page that is constructed
from the contents of this resource. As an example, consider
a web-based bulletin board system, where people can post
messages that are displayed to all visitors of the bulletin
board. Let us assume further that the application does not
remove script content from posted messages. In this case,
the attacker can craft a message similar to the one in Figure
(2). This message contains the malicious JavaScript code,
which the bulletin board stores in its database. A visiting
user who reads this message retrieves the scripting code as
part of the message. The user’s browser then executes the
attacker’s control.
IV. Methodology
A. Detection of XSS
In this paper we will execute four producers to treat the
Crosse site scripting injecting by the server side. at first
we’ll detect the script by using the lexical analysis to
analysis the entered statement in the search box of our
web site, put it in an array, check if the statement
contain ‘<’, if yes, insert all the literals in an array until
‘>’ or ‘=’ has been reached and finally convert the array
to string as shown in the next algorithm steps:
- S = [statement]
Array [0, 1, 2…., i].
- For (S=0 to i)
- If (S==<)
- Insert S
Y array[S]
- While (S != ‘>’ or ‘=’)
- Insert S
Y array[S]
- End
- Conv. Y array[S]
X array[S=string]
script, which, in turn,
B. Comparsion Tags
Show at this image!
In the second part we compare the resulted string from
<img src="image.jpg">
the privous part with the database which contain the
<script>
XSS statement, if found threat then has been detected
4
otherwise add the tag to database as shown in the next
[4] Jagatic, T., Johnson, N., Jakobsson, M., and Menczer, F.
algorithm steps:
Social Phishing. To appear in Communications of the ACM.
- Comp. X[S] && MYSQL_DB[S.XSS]
- If (S == S.XSS)
- Print (Threat has been detected).
- Else {
- Insert S
MYSQL_DB [new S.XSS]
C. Register the threat
[5] A. Klein. Cross Site Scripting Explained. Technical
report, Sanctum Inc., 2002.
[6] OWASP, OWASP Top 10 Project. Available at:
http://www.owasp.org/index.php/Category:OWASP$_$Top
$_$Ten$_$Project. 2010.
In third part take the name of the attacker and check, if
it in the session table name inserts the location and time
and name as shown in the following algorithm steps:
- If [attacker name] == Session[name]
- Insert
Intrusion table [location, time,
name]
[7] Fourth dimension, Stealing Cookie With XSS. Available
at http://www.go4expert.com/forums/
showthread.php?t=17066, 2009.
[8] Asha U. Patil, Arati M. Dixit, Web Guard: Enhancing
Intrusion Detection in Multi-tier Web Applications ,
Volume 95– No. 9, June 2014
D. Delete the user from the authorized users table.
Finally, delete the user if he is a member in the web site.
As shown in the following algorithms steps:
- Del. [name]
Auth.Table[users.name]
V. CONCLUSION
In this paper we present a method to detect and prevent XSS
at the server side by follow the lexical analysis and compare
with the stored XSS statement in the database, district the
malicious injection, store the new XSS statement to know
the new malicious injections, and eliminate the attacker by
delete him from the members to prevent his future attack.
VI. REFERENCES
[1] Jeremiah Grossman , Robert “RSnake” Hansen, Petko
“pdp” D. Petkov, Anton Rager, XSS Attacks-cross site
scripting exploits and defense, technical Editor and coauthor.
[2] Dafydd Stuttard, Marcus Pinto. The Web Application
Hacker’s Handbook-Discovering and Exploiting Security
Flaws. 2007
[3] Prahlad Fogla,Monirul Sharif, Roberto Perdisci, Oleg
Kolesnikov &Wenke Lee: Polymorphic Blending
Attacks. In: Proceedings of the 15th USENIX Security
Symposium, 2006, pp. 241–256.
[9] Tejinder Singh, Detecting and Prevention Cross –Site
Scripting Techniques, IOSR Journal of Engineering
Apr. 2012, Vol. 2(4) pp: 854-857.