How to test for cross-site scripting?

XSS vulnerabilities come in various different shapes. There is no one golden payload that works in every case. On the one hand, you can go ahead and try payloads listed on pages like OWASP’s XSS filter evasion cheatsheet.

On the other hand, it is not recommended to spread payloads over an application that you don’t understand. For now, we will learn one easy strategy and will move on from there.

Non-Intrusive Testing

Try using the <b></b> HTML tag enclosure to print out an example text in bold letters, e.g. <b>this is where I am testing my XSS payload</b>.

This is a non-intrusive way to check if greater than > and less than < characters are allowed to be used. In case your example text is printed bold, you have enough evidence that those characters are not getting encoded. You can also check for that in the browser’s developer tools. The reason we are testing for exactly those two characters is that they are needed to insert HTML tags. Being able to add new HTML to a page is still the number one indicator for a potential XSS vulnerability.

Moving on from there, you can try a vast amount of different payloads. We recommend you have a look at Portswigger’s XSS cheatsheet for inspiration.

Videos

Let’s watch some videos to get a better idea of how to test for cross-site scripting vulnerabilities.

In the first one, we are going to have a look at an application that blocks certain HTML tags and event handlers. Let’s find out about a quick way to circumvent that control.

In this second video, we are looking at the basics of DOM-based XSS. Let’s get a better understanding of the browser’s developer tools, the Javascript debugger and about the whole concept of sources and sinks.

More videos to come soon!