The greatest danger of a cross-site scripting (XSS) vulnerability is the possibility of spreading from user to user of an application until the whole user system get infected. Such code capable of doing that is what we call an XSS worm.

In order to better understand how this digital creature works, we will start a brand new journey into the mechanics of the self replicating code needed to make this danger exist.

As always, for didactic purposes, we will keep it simple as possible making use of the essential things only. So we will avoid the use of XHR and similar javascript proceedings, better suited for more complex applications which is not our goal.

Let’s see the simplest case of self replicating XSS, a reflected one. The code below is only the needed to replicate itself.

<a href target=_blank>click</a>

It simply injects a link which will open the current page with the same injection in another browser tab.

Try it here.

Now let’s see a more elaborate one. This page is meant to be used to post comments and it’s vulnerable to stored XSS.

If we use the following code as comment:

<form method=post onclick=elements[0].value=outerHTML;submit()>
<input type=hidden name=comment>click me!</form>

We will be able to make a copy of the injected code every time someone click on “click me!”.

That injection is a form, allowing us to submit content using the POST HTTP method (method=post). When clicked (onclick) it will take the 1st element of the form (elements[0]) which is <input> and set its value to the outerHTML property of the form. This property returns all between <form> and </form>, included. After, the form is submitted (submit()). The input tag contains the string to be clicked (click me!) and the name of the POSTed variable (comment).

For a vector with less user interaction, we can use the event handler onmouseover or similar with CSS tricks to increase the likelihood of triggering to almost automatic.

Although useful, the form tag is unlikely to be allowed in a comment box. The reflected one is much more likely, but not that dangerous. So we will make use of both, combined.

The following code uses a reflected XSS to store a link pointing to itself, so it can spread by means of another user:

<form method=post action="//brutelogic.com.br/tests/comments.php"
onclick="elements[0].value='<a/href='%2BURL%2B'>link</a>';submit()">
<input type=hidden name=comment>click me!</form>

It works by making a POST request to the comments page (action attribute), like the previous stored example. But instead of using outerHTML to recreate itself in the comment, it creates an anchor (“<a/href=” and “>link</a>” parts) using the value of the current URL document property (URL). It does that by concatenating (%2B is “+” encoded) the tag to the property.

It’s worth to note that usually it’s possible to submit anchors in comments, filters don’t use to block them. All we need is the reflected vulnerability on the same site.

Try it here.

In order to make the attack stealthy, without returning the user to comments page, we add an invisible iframe and point the form to it, with an extra “target=NAME” attribute:

<iframe style=display:none name=x></iframe>
<form method=post action="//brutelogic.com.br/tests/comments.php"
onclick="elements[0].value='<a/href='%2BURL%2B'>link</a>';submit()"
target=x><input type=hidden name=comment>click me!</form>

Open a tab with a clean comments page (drop comments) and try it here.

In the next part of this series, we will see an unique experiment: the spreading of an XSS worm among several users of a custom social network (a controlled environment) using this code.

#hack2learn