Disclaimer: This post is for research and educational purposes only. I do not take any responsibility, in regards to the actions taken by readers of this article. Never attempt to hack a device for which you do not have the required permissions to do so.

If you haven't read Part 1, i highly recommend that you do so. It is really important to understand the basics.  

Persistent Cross Site Scripting (XSS)

Now this type of XSS can be really lethal for a website. With this kind of vulnerability attackers can do anything they want with the website. Including things like defacement, key logging, ad jacking and so much more. The reason why this type is dangerous is because the script and its effects are stored on the web server. So even after refreshing the web page, the script will keep getting executed. Persistent XSS is highly sought after, many companies pay huge amounts to bounty hunters who find such bugs on their website.

But it needs to be something which interacts with the database or file storage, For example, comment boxes and submission forms.

Lets take a look at an example

The form above, takes two inputs, a name and a message and stores them onto a database. So as usual we insert a script into it


Now every time you refresh your page, the script will keep getting executed, because its stored in the database now.


DOM Cross Site Scripting

DOM-based XSS is a mixture of persistent and reflected XSS. In a DOM-based XSS attack, the malicious string is not actually parsed by the victim’s browser until the website’s usual JavaScript is executed. In this case there is no malicious script inserted as part of the page; the only script that is automatically executed during page load is a legitimate part of the page. The problem is that this legitimate script directly makes use of user input in order to add HTML to the page. Because the malicious string is inserted into the page using innerHTML, it is parsed as HTML, causing the malicious script to be executed.

The difference is :

  • In Reflected and Persistent XSS, the malicious JavaScript is executed when the page is loaded, as part of the HTML sent by the server.
  • In DOM-based XSS, the malicious JavaScript is executed after the page has loaded.

There can be a unique case of DOM-based XSS in which the malicious string is never sent to the server of the website to start with: if the malicious string is in the snippet identifier of a URL. Browsers will not send this portion of the URL to servers because there is no way for the website to access it using server-side code. Nevertheless, the client-side code has access to it, and can therefore trigger XSS vulnerabilities through improper processing.

For example,

Now instead of English, i could add this script:

this is the result

and his is how DOM based XSS works.

How to avoid Cross Site Scripting vulnerabilities?

  • Encoding the input, which escapes the user input so that the browser interprets it only as data, not as code.
  • Validating input, which filters the user input so that the browser interprets it as code without malicious commands.
  • Secure input handling can be performed either when your website receives the input or right before your website inserts the input into a page.
  • Limit use of user-provided data.
  • Use CSP, it is used to constrain the browser viewing your page so that it can only use resources downloaded from trusted sources. Example, a script, a stylesheet, an image, or any file referred to by the page. This means that even if an attacker succeeds in injecting malicious content into your website, CSP can prevent it from ever being executed.

Hopefully, now you have a better understanding of Cross Site Scripting.

For XSS payloads : Click Here

If you want to practice your XSS skills you can do it on these platforms.