They are not necessarily exclusive. They take advantage of different weaknesses. If you have the ability to do a "traditional" XSS through a reflected attack, then you likely wouldn't need to attempt a dom-based attack because you can inject any code you want before the page loads.
In your examples, its not quite clear if you are differentiating the root difference.
In a traditional XSS you are sending the payload as part of the request to the page. The server adds your script to the page and then serves the response to the victim.
DOM-based XSS happens all on the client side, e.g., the data is read by JavaScript directly from the URL, title, an input field, etc.
For example, you start with a GET request like somesite.com/index.php?someVar=foo
we make someVar equal to <script>alert(1)</script>
In a reflected XSS the variable someVar is read in by the server and then becomes part of the response page. So if there is PHP script for index.php like:
echo "<h1>Welcome</h1>";
echo $_GET['someVar'];
The rendered HTML will be:
<h1>Welcome</h1>
<script>alert(1)</script>
Now in reality, if the attacker could drop in a script to do whatever they want. Basically, they have full control and can execute any commands they want. There may be an impact based on when in the flow the code is executed, but essentially they have control of the page rendered to the victim.
On the other hand, let's start with the same URL:
somesite.com/index.php?someVar=foo we make someVar equal to alert(1)
In this case, the PHP file looks like this:
echo "<h1>Welcome to URL Check</h1>";
echo "<script id="someVar"></script>"
?>
<script>
document.getElementById("someVar").innerHTML = getURLParameter('someVar');
function getURLParameter(name) {
return decodeURIComponent((new RegExp('[?|&]' + name + '=' + '([^&;]+?)(&|#|;|$)').exec(location.search)||[,""])[1].replace(/\+/g, '%20'))||null
}
</script>
</body>
Now, I will admit this is a pretty odd way of doing things, but it demonstrates how the same input could be used in both the dom based context and the reflected context.
Now it certainly possible for there to be a scenario where you need to use an reflected XSS based attack to then leverage a DOM based attack:
Again, given somesite.com/index.php?someVar=foo we make someVar equal to alert(1)
<?php
echo '<h1>Welcome</h1>';
$someVar = $_GET['someVar'];
echo '<span id="watch1">' . $someVar . '</span>';
echo '<script id="watch2"></script>';
?>
<script>
document.getElementById("watch2").innerHTML = document.getElementById("watch1").innerHTML
</script>
In this example, the malicious input comes as part of the request and the value is assigned to some part of the HTML. Then when the client side JavaScript is executed, it calls that input. The actual attack happens on the client side because of reading input. This may not be considered dom-based XSS in the purest sense anymore.
To prevent a reflected XSS attack, usually you will do your filtering/sanitization on the server side; for a dom-based attack you need to do your filtering/sanitization on the client side because the client is taking in input directly from elsewhere in the client.
Note: getURLParameter from
David Morales
