An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

According to OWASP definitions “Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.

There are 3 types of XSS:

  • Reflected XSS or Non-Persistent XSS.
  • Stored XSS or Persistent XSS.
  • DOM based XSS.

1.Reflected XSS or Non-Persistent XSS:

Attacker will write some malicious scripts and craft it in an image or in the form of short URL and delivered via email. Whenever the user clicks on that, the script will get executed and performs their action which is already specified by the attacker. It will execute in the browser side.

In this attack an attacker is targeting the particular user.

The below diagram shows the working flow of Reflected XSS

Simple Attack scenario for Reflected XSS:

Attacker knows the site which is vulnerable to Reflected XSS; he will prepare a link such a way that whenever user clicks on that link he will get redirect to malicious website along with revealing his cookie information to the attacker.

Step 1:

User logged in to his account with his credentials.

Step 2:

Suddenly user got one link to “click here” that is crafted with malicious code which will send the session ID along with it will redirect to some Phishing sites.

After clicking Ok it will automatically redirects to the attacker website.

2.Stored XSS or Persistent XSS:

In this attack, an attacker will write malicious script and host itin the web serverto get user’s sensitive information that maybe Session ID or Credentials or Cookies information. The script will store in the server, whenever the user clicks on that post or visits the infected website the request goes to the server and executes the script.

It is more dangerous compare to Reflected XSS, because it will be stored in the Server. Hence every user who is going to visit this site will get affected.

Sometimes attacker will create the phishing page which is very much similar to the real one and host it in the server and redirecting the users to that page by using XSS.

Most probably Stored XSS will happen in comment fields, feedback fields etc., basically wherever the user input is going to store.

The below diagram shows the working flow of Stored XSS

Simple Attack scenario for Stored XSS:

Attacker knows the site which is vulnerable to Stored XSS; he will write a script and stored it in the server. Whenever the visitor going to visit this site will get affected.

Step 1:

Attacker found that, the below form field is vulnerable to Stored XSS.

Step 2:

An attacker has written the Script in the Message box and click on the submitbutton. It will get stored in the Server.

See the difference between previous and below fig…, In Message list one entry is added

Step 3:

Whenever the visitors visits this page, they will find something interesting “Hi congrats you have won the gift Voucher, to claim your voucher please click here” as shown in the above diagram after seeing this, the user will click on this and he will get affected by XSS.

3.DOM based XSS:

DOM (Document Object Module) XSS is common vulnerability in Web application, which occurs due to bad Script coding, Vulnerability which allows Client-Side-Scripts for Eg: (JavaScript), an attacker can modify webpage content to do attack.

Simple Attack scenario for DOM based XSS:

The DOM based XSS is bit advance and difficult to find: because finder must scan each parameter and JavaScript and they should have the knowledge of JavaScript to understand the scripting.

Step 1:
Attacker found that, the below Web page is vulnerable to DOM based XSS.

Step 2:
Right click on the page and open source code and search for tag in the Source Code.

By seeing the script attacker got to know that JavaScript gets value from the URL Parameter “name”

Step 3:

Attacker found URL Parameter “name” by analyzing script in the source code.& by using burp suit attacker encodes the script as URL.

Just enters the encoded script at the end of the URL as shown below


And craft it as a link and sends to the victim via email or put it in the website itself

Step 4:

When victim clicks on the link the script will get executes and performs malicious actions.

The two most common methods of attack are:

  • Clicking on a URL link sent in an e-mail
  • Clicking on a URL link while visiting a website

Why XSS:

  • To sniff the user credentials.
  • To sniff the cookies information.
  • To redirect some other pages.
  • To pop up messages.
  • To do business loss of others.

Where to check the XSS:

  • Text boxes.
  • In the URL, if User input is going in the URL.
  • Form fields.
  • Search fields.
  • Comment fields.
  • Wherever user data is visible in source code.

How to test for XSS Injection vulnerabilities in URL:

A simple and easy test is to take a current parameter that is sent in the HTTP GET request and modify it.

Take for an example, the following request in the browser address URL. This URL will take a name parameter that you enter in a textbox and print something on the page. Like Hello Sanjay, thank you for coming to my site.

Modify the above URL instead of Sanjay write some script as shown below Or else encode the script as URL and try.

If this pops up an alert message “XSS Vulnerability Found”, then it confirms that the parameter is vulnerable to XSS. Which means it is not validating the input value.

There are so many different methods to test XSS

If they were filtering keywords like alert, prompt and so on.., means then try with the all combinations of upper and lowercase or else concatenation.

Eg: Instead of ‘alert’ use ‘al||ert’ and so on..,

Use different combinations which will cause the same effect in the sense use concatenation operator to bypass the keyword filters.


  • Cookie should be “tied” to a particular IP address & MAC address with Session login time so that hijacked cookies will fail in the validation when employed by cross-site scripting exploits.
  • Internet Explorer implements an HTTPOnly flag that prevents local scripts from affecting a cookie, but it is ineffective against cross-site request forgery attacks.
  • Along with the client side validation, Server should validate the request before processing.
  • Consider each and every input from the user as a data and not as a script, and disable java script if it is not required.
  • Input Validation is very important. The developer needs to validate the input as it’s coming in. But additionally the output needs to be verified. The output should be correctly html encoded. If the output is correctly encoded, then instead of executed the tags, they would be html encoded and not cause the vulnerability.
  • Hide the Scripts from the source code.
  • Code the scripts properly and don’t send it in the URL.
  • Filter the keywords which will be used in XSS attack i.e Sanitizing (Eg: script, alert, prompt, redirect, location etc..,).
  • Whitelist the valid inputs wherever possible.