XSS is again in the OWASP Top 10 Vulnerabilities that are announced in 2017. XSS vulnerability is exploited in web applications. This vulnerability occurs when an attacker will insert untrusted data /scripts into web forms. The attacker does not directly target the victim but exploits website that the victim is visiting to deliver malicious content.

JavaScript is most commonly used to develop malicious content and it is a common language used to develop the website. Because of using the same language, malicious content also appears to be a legitimate part of the website. However, it is unknown to the victim and assumes that it is normal behavior of Website.

The only way for the attacker to run malicious JavaScript in victim’s browser is to inject it into one of the pages in a website.

Malicious JavaScript gets executed in the browser and here is what it can do

  • Capture Session Cookies
  • Send/receive arbitrary content to/from another website
  • Deface the Web page
  • Take over the account, that victim is currently logged in.
  • Bypass Multi-Factor Authentication
  • Perform DOM Node Replacement
  • Download Malicious software’s to the Victim PC
  • Enable Key Logging feature, to capture the victim keystrokes

Who exactly are involved?

  • The server, which hosts the Website
  • The Database, where Data is stored
  • A Victim user, who visits the Website
  • An Attacker, who try to attack the Website


Reflected XSS:

  • Malicious string/data originates from the victim’s request.
  • Typically, a user will need to interact with some malicious link that points to an attacker-controlled page.
  • Not stored in the application.
  • Only impacts users when they open a malicious injected web page.
  • Javascript, ActionScript, and VBScript are the languages used generally.




  1. The attacker will insert malicious Scripts into the website through any of the available input fields/ forms.
  2. This script will be processed by the Website and will give an output to the attacker on the website confirming the execution of a script.
  3. Once the attacker gets a confirmation, he crafts a URL containing malicious script and sends it to the legitimate user.
  4. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser.
  5. The browser then executes the code because it came from a “trusted” server and pass on user information to the attacker.

Stored / Persistent XSS:

  • The malicious string/data comes from the website’s database.
  • Stores that input in a database.
  • Typically, JavaScript is used.



  1. The attacker uses one of the website’s forms to insert a malicious script into the website’s database.
  2. The poorly coded website will take the input provided by the attacker and it processes the malicious scripts and stored it in the database.
  3. A legitimate user, who visits this website form and request for some data from the website.
  4. The users’ request will be processed by the website and fetch the required data from Database which includes malicious scripts.
  5. This response from the database will be served to the end user by the website.
  6. At the user end, this data will be executed by the Browser and will cause issues and can also send user information to the attacker.

DOM Based XSS:

  • This vulnerability is in the client-side code rather than server-side code.
  • Commonly observed in JavaScript frameworks, single-page applications, and APIs.
  • JavaScript is used.



  1. An attacker, request a webpage/form from the targeted website.
  2. The Static and Dynamic content is loaded in the webpage will be served to an attacker, as it is a legitimate request.
  3. An attacker will try to identify and modify DOM parameters in the website and try to fiddle with them by manipulating the way variables are processed.
  4. Now attacker crafts a URL containing a malicious script and sends it to the user.
  5. The user is tricked by the attacker into requesting the URL from the website.
  6. The website receives the request but does not include the malicious string in the response.
  7. The user’s browser executes the legitimate script inside the response, causing the malicious script to be inserted into the page.
  8. The victim’s browser executes the malicious script inserted into the page, sending the user data to the attacker’s server.

Sources for XSS & Recommended prevention

Attack Vectors

Input Forms are the common attack vectors for XSS and some of them can be

  • User/Profile page: the application allows the user to edit/change profile details such as first name, last name, nickname, avatar, picture, address, etc.
  • Shopping cart: the application allows the user to store items into the shopping cart which can then be reviewed later.
  • File Manager: the application that allows upload of files.
  • Application settings/preferences: the application that allows the user to set preferences.
  • Forum/Message board: the application that permits an exchange of posts among users.
  • Blog: if the blog application permits to users submitting comments.
  • Log: if the application stores some users input into logs.

Some of the preventive measures are

  • Encoding, which escapes the user input so that the browser interprets it only as data, not as code.
  • Validation, which filters the user input so that the browser interprets it as code without the malicious script.
  • Context Secure input handling needs to be performed differently depending on where in a page the user input is inserted.
  • Inbound/outbound Secure input handling can be performed either when your website receives the input (inbound) or right before your website inserts the input into a page (outbound).
  • Content-security-policy(CSP) is used to constrain the browser viewing your page so that it can only use resources downloaded from trusted sources. A resource is a script, a style sheet, an image, or some other type of file referred to by the page.


Author: Priyanka Ratakonda

SecuArk Pvt.Ltd