Cross Site Scripting

Posted: January 24, 2013 in Application Security

Cross-Site Scripting also known as an XSS is a kind of a vulnerability typically exist in most of the web applications. Every web application has “Same-origin” policy because of which the application executes only its own script. XSS enables the attacker to break the “same-origin” policy of the application and insert malcious script or code into the web-pages.

Attacker can perform different kinds of attacks by using using XSS. Few of them are

  •  Stealing Credentials
  •  Stealing Session ID (cookie value)
  •  Defacing the Web-site
  •  Causing DOS (Denial of Service) and many more….

XSS exists in different forms:

  •  Reflected or non-persistant XSS
  •  Stored or Persistant XSS
  •  DOM Based XSS

Destiny is same but the approach is different. All these types of xss are used for the same purpose and there are several features in common but the flavors(identifying and exploiting) are different 😀

Reflected XSS:
This kind of vulnerability normally exists in the application that uses dynamic pages to display content to the user (for ex: error messages). In general these applications takes a parameter containing a message and simply renders back to the user.
Consider the URL :

Above url shows a message “learn hacking” in the response of the application. Here the application extracting the message from the url, processes and displays to the user. So the url processes user supplied input and inserts it into the servers response that leads to REFLECTED XSS. And if there is no proper sanitization then the application is definitely vulnerable to Reflected XSS.

The attacker can form a crafted url as follows:<script>alert(1)</script&gt;

Requesting the above url generates the page that contains the script and displays the alert message.

Exploiting the Reflected XSS:


  1. User login’s to the web application and application issues an unique id (session id)  to the URL
  2. Attacker sends crafted URL to the user through some means of communication
  3.  User requests the crafted URL fed by the attacker 
  4. Server processes the url and responds to the user’s request. As the URL is framed with the malicious script, script is executed in the user’s browser in the same way it does on other code.                                                                                                                                                                                       Assume the attackers url is framed as :;
  5. The code causes the browser to send a request to And the request contains current session id
  6. Attacker uses the Session Id or Cookie Id and hijacks the users session. Now the attacker can perform all the actions in the same way how the user does.

Stored XSS:
This type of vulnerability is quite difference from the Reflected XSS. Normally these kind of vulnerability exist when an application takes an input from the end-user and stores it in the application, then displays to the other users.  For example: Consider Facebook application which allows to comment on pictures or status updates and then displays to all other users on their wall. If the application doesn’t sanitize the input properly then an attacker can write a script in the comment area, so that the users who visits or views particular page or post will be effected.  These kind of vulnerability normally exists in forums, bidding applications etc…..

So Stored XSS attacks typically consists of two things to do.. Initially the attackers visits the application and enters the malicious script into the application. Secondly the user enters into the application and visits the vulnerable page. And the script is executed in the back-end without the knowledge of the user.

DOM Based XSS:

DOM Stands for Document Object Model. To know how this attack works firstly we need to now what is DOM. Find the details from here. DOM Based is quite different from Reflected and Stored XSS. In DOM based when the user clicks on the crafted URL, server response doesn’t consist of any attackers script. Instead the browser executes the attacker’s script while processing the response.
This is because the Document Object Model of the browser has a capability to determine the URL used to load the current page. Script issued by the application may extract the data from the URL and process it. Then it uploads the content of the page dynamically depending upon the script executed through the URL.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s