As the name
implies, Cross Site Scripting means a sort of Scripting that is done outside the
scope of the website. For example: A website is providing a text box to input
inside that text box to execute those scripts on the server or anyway.
Scripting� abbreviated as �XSS� not �CSS� as �CSS� has already denoted for �Cascading
must know the serious consequences of XSS when exploited on a vulnerable web application.
Site owners says that it cannot be used to steal sensitive data from their database.
This is a common mistake. There are stories where it was claimed that XSS is not
really a risk. and this is someting a challenge for the hackers and that hackers
always willing to accept,
A practical example of XSS on a test site...
example shows how XSS can be used to modify the functionality of a web page and
to re-design the page as per the hackers will: [third
Load the following
link in your browser:
http://testasp.acunetix.com/Search.asp, you will notice that the page is a simple page with an input
field for running a search
Try to insert
the following code into the search field, and notice how a login form will be displayed
on the page:
<br><br>Please login with the form below before proceeding:<form
type=text length=20 name=login></td></tr><tr><td>Password:</td><td><input
type=text length=20 name=password></td></tr></table><input
hit the search button after inserting the code.
XSS flaw on the page, it has been possible to create a FAKE login form which can
gather a user�s credentials. As seen in step 2, the code contains a section which
mentions �destination.asp�. That is where a hacker can decide where the FAKE login
form will send the user�s log-in details for them to be retrieved and used maliciously
A hacker can
also inject this code by passing it around via the browser�s address bar as follows:
It is the
feedback. This feedback may contain many things; one, most commonly being
the user's cookie. A cookie is the variable that web-browsers use to store your
login credentials. Without a cookie, you cannot "stay logged in" on your favorite
websites. This is important because if somebody were to obtain your cookie, he/she
could easily spoof your login information without any need of knowing your password.
XSS is, in my opinion, the most common and dangerous exploit that exists on the
internet today. It is dangerous because it is common (and useful), and it is common
because it is most overlooked. Most WebPages today are user-interactive, which basically
means that the website allows the user to interact with its content. Some of this
interactivity may include search fields (most commonly), login forms, comment fields,
feedback forms etc..
can be termed as such attacks that bypass the system checks and act themselves as
a part of the system. This mainly happens due to the non-sanitizing structure
of HTML that has the capability to take any command [ in the proper tags ] and to
display it on the user end. One single hole in the website that allows to enter
scripts can harm anything in the website, that can be any page content, cookie(s),
link(s) or even the Page redirection statements on the client side.
Most of the
big brands in the website colony has became the prey of XSS like Yahoo, Google,
Orkut and Facebook with the loss of huge revenue. Now they have controlled the threat
but not cent percent. Each and everyday more than 50% of the new websites are targeting
for the XSS attacks due to their weak security and validation structure.
There is no standard way of injecting
XSS into any website. Even it is not necessary to have the XSS code inside the <Script>
tags. This may
be any method, any combination of characters, even in the Hexadecimal format XSS
can insert, but the main measure is that how the website accepts the input from
the user and what type of input it accepts from the user.
How it works
structure is such that it accepts every command or phrase withing the tags( <\>
) and hence there is a possibility to insert any tag(s) in a page that afterwards
could act as a part of the same page with other HTML tag(s).
At the first
sight, it seems that the effect of the XSS is limited to only one user and previously
at the beginning days of XSS the malicious scripts were responsible for the damage
of User interface and some images only, but as the resources grew, technology advanced,
the way of XSS injection changed tremendously.
We can divide
the XSS threats in two ways:
1. Non Persistent
Non Persistent Scripts: If XSS attack is for some limited
area only, eg: to change the behaviour, font, color of the website only then it
is somewhat that can control.
Persistent Script: But if the XSS attack is something that resides in the
Server that can be more harmful for the complete system. Persistent XSS attack can
even lead the complete system to be hacked.
the user searches for something and the input is reflected on the page, this may
show signs of XSS possibilities. If the user were to search for <script>alert(1)</script>,
and the returning page contained and alert box that read "1", the field is also
vulnerable to XSS Injection.
2. HTTP Response Splitting
has something to do with the headers that your browser uses to communicate to the
server with. If the webpage allows you to modify them via post or get vars, and
reflects the information back, you can easily modify these headers to your needs
in order to cross-site script the page. Most commonly, the header's that are XSS'able
are the User-Agent: headers. Most pages don't sanitize the user agent when reflecting
back the user's browser properties (most commonly on a 404 page.)
the attacks were limited to the HTML only. for eg: I have to display my name in
Bold and in Red Color and the website in which my profile is, not allows Text Formatting
then i can add my name in tags like <Font color = �Red� Bold = �True�>MyName</Font>
and then i will save this string and if the website is simply displaying my name
then this string will be treating as a part of HTML of the same page and the name
will appear Bold and Red every time as the string �<Font color = �Red� Bold =
�True�>MyName</Font>� is saved in the database.
a user's first name around from one page to another and then are displaying that
querystring value on the page with a Response.Write, here you are increase the chances
Now you want
\\" + Request.QueryString(\\"fName\\"));
When you run
this code you get the following output:
more that would produce the "Hello Lumpy" output:
But here is
now, the browser
will popup a nice little box telling you "beotch"!
Any code you
out this next line...
I send someone
a valid link to a URL, maybe they do make it to the site, but they also get something else...
But now a
day(s) due to advent of new technologies like AJAX, DOM model(s), the situation
is somewhat grave. How?
user finds some information in a social networking website as follows:
- Span tag
(if available) or tag information of the �Sign Out� button, say the id of the <span>
tag of Sign out is �spSIgnOut�.
- a page where
the user can enter text or Scraps.
- all the
input controls on the page [including hidden controls by using the Source of the
Web page ].
- all the
input controls of which information saves in the database on postback.
Here to understand
we assume that the website is not optimized for XSS attacks.
Now the malicious
user enters a script in one of the text box inside <script> tag, in the script
the user changing the InnerHTML of the span tag �spSignOut�:
change the innerhtml of the sign out span with the alert(�you cannot sign out of
this command, the malicious user saves the scrap. Now on the opening of the same
scrap the html link of the sign out link will have been changed. And this is inside
the database, it will happen again and again. And by this way the malicious user
would have been changed the HTML by XSS.
You can now
imagine how dangerous the XSS is.
You can use
some measures to avoid this like:
and Decoding of Tags if present in any input
the Response and Request data on each postback.
But can the traditional methods
can stop the XSS threats??
I think NO
because here are some other methods to inject XSS like:
ways even i dont know
So enjoy the article and in next
Version 2 , I will share some more about the �XSS�
Error in Documentation? Can't find what
you are looking for? Let us know!!
Back to Blog