What is Cross-site Scripting (XSS) and why is it so important?
XSS enables the injection of client-side instructions into a web application that is viewed by other users. In case you’re wondering what can go wrong with that, just think about an attacker grabbing your session id, which will enable a session-hijacking, which effectively means stealing your identity in the web application. This, in combination with the XSS vulnerabilities being at the top 3 of the OWASP Top Ten web application vulnerabilities, makes this kind of attacks very valuable.
Start your DVWA web application and navigate to the Reflected Cross Site Scripting (XSS) section.
The form is asking for our name, so let’s say we are John Smith :
If we send this url to a victim and the victims clicks on it, then we’ll get her cookie, if of course she is logged in the web application.
Now you might think “Well, I would never click on a url that has script tags in it”. Sure, but that can be fixed by just encoding the url:
Much harder to see that it’s an XSS attack, isn’t it?
Our exploit is not finished yet, since instead of showing an alert to the victim, we actually want to send the cookie to a server that we control for example, so we can take over the victim’s session. We’ll skip this part since it’s out of scope for this post.
Let’s open the Stored XSS section of DVWA. It’s asking for a name and a message, let’s say we are John Smith and put Hello World as the message:
In order to get rid of the annoying pop up, re-create the DVWA database