Exploiting Cross-site scripting vulnerabilities

Datetime:2017-04-16 05:17:19         Topic: XSS Vulnerability  JavaScript          Share        Original >>
Here to See The Original Article!!!

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.

The anatomy of the attack is very simple. Consider any user input as an attack surface, where you can enter javascript code in it. If the web application returns this input to the client without encoding the ‘<’ and ‘>’ characters then the browser will interpret the script tags as trusted javascript instructions sent by the web application and it will execute it. From that point, we can get access to the web page’s cookie:


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 :

Now, let’s inject the javascript code from above:

Boom! We got the cookie, but that’s our cookie, isn’t it? How can we get another user’s cookie? The user input is sent to the server as GET parameters, so we have our javascript code at the url:<script>alert(document.cookie)</script>

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.

As you might have noticed, DVWA lists this vulnerability as a Reflected XSS , and there is one more called Stored XSS . The Reflected XSS attacks are those where the victim needs to submit the injected code itself (you can remember it as the attack being reflected to the web server through the victim’s browser). On the other hand, the Stored XSS attack is the case where we manage to persist the javascript code at the web server itself. That’s the most powerful XSS attack, since any user visiting the web application, will be served our injected javascript code. One recent Stored XSS attack was found against Twitter , and the persisted javascript was retweeting the original tweet, whenever this tweet was rendered to the timeline of any user

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:

Now, let’s inject our javascript in any of the two fields:

Our javascript code is stored in dvwa’s database and served every time the page is visited!

In order to get rid of the annoying pop up, re-create the DVWA database

Happy injecting!