Cross-site Scripting (XSS)

XSS is a code-injection type which is performed on the client-side. By using this type of attach, the attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, and the website will be the bridge between the attacker and the victim’s browser.

The most common programming language to perform this kind of attacks is JavaScripts, but it also can be used VBScript, AxtiveX and Flash instead.

Types of Cross Site Scripting

XSS attacks are broadly classified into 2 types:

  1. Non-Persistent
  2. Persistent

1. Non-Persistent XSS Attack

It requires a user to visit the specially crafted link by the attacker. When the user visit the link, the crafted code will get executed by the user’s browser.

Example for Non-Persistent XSS


Example 1:

You can build an anchor tag and put a link with some custom script on the URL and send it to the victim:

When the victim load the above URL into the browser, he will see an alert box which says ‘attacked’. Even though this example doesn’t do any damage, other than the annoying ‘attacked’ pop-up, you can see how an attacker can use this method to do several damaging things.

Example 2:

You can also change the destination of a link, and when the user clicks to go to, you can force it to be redirected to

Normally an attacker tends not to craft the URL which a human can directly read. So he will encode the ASCII characters to hex as follows.

which is same as:

You can use the following tool to convert the URL from ASCII to HEX:

Now the victim may not know what it is, because directly he cannot understand that the URL is crafted and their is a more chance that he can visit the URL.

2. Persistent XSS Attack

In case of persistent attack, the code injected by the attacker will be stored in a secondary storage device (mostly on a database). The damage caused by Persistent attack is more than the non-persistent attack. Here we will see how to hijack other user’s session by performing XSS.


HTTP protocol is a stateless protocol, which means, it won’t maintain any state with regard to the request and response. All request and response are independent of each other. But most of the web application don’t need this. Once the user has authenticated himself, the web server should not ask the username/password for the next request from the user. To do this, they need to maintain some kind of states between the web-browser and web-server which is done through the “Sessions”.

When the user login for the first time, a session ID will be created by the web server and it will be sent to the web-browser as “cookie”. All the sub-sequent request to the web server, will be based on the “session id” in the cookie.

Examples for Persistent XSS Attack

This sample web application we’ve given below that demonstrates the persistent XSS attack does the following:

  • There are two types of users: “Admin” and “Normal” user.
  • When “Admin” log-in, he can see the list of usernames. When “Normal” users log-in, they can only update their display name.



Now the attacker log-in as a normal user, and he will enter the following in the textbox as his display name:

The above information entered by the attacker will be stored in the database (persistent).

Now, when the admin log-in to the system, he will see a link named “My Name” along with other usernames. When admin clicks the link, it will send the cookie which has the session ID, to the attacker’s site. Now the attacker can post a request by using that session ID to the web server, and he can act like “Admin” until the session is expired. The cookie information will be something like the following:

Once the hacker knows the PHPSESSID, he can use this session to get the admin privilege until PHPSESSID expires.

To understand this more, we can use a firefox addon called “Tamper Data”, which can be used to add a new HTTP header called “Cookies” and set the value to “PHPSESSID=vmcsjsgear6gsogpu7o2imr9f3”.



Leave a comment