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
innerHTML, it is parsed as HTML, causing the malicious script to be executed.
The difference is :
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.
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.