To go on the previous article, I got a lot of questions about JS Judo about what it does or is supposed to do. So I thought a couple examples would fit nicely to illustrate the issues surrounding re-usual of resources already available when a XSS or SQL injection vulnerability has been found. To me there are two different advantages attackers have with this kind of technique.
1. minimize vector injection
2. avoid exotic signature detection.
1. When writing a worm to propagate across a social network website, it can be important for an attacker to minimize the worm size. The following worm vector that I presented in the diminutive XSS worm contest is already 203 bytes long and can fit inside almost any database field, but it's payload is only a XSS alert box.
This worm is self propagating:
<b>
<img src="" onerror="
with(new XMLHttpRequest)
open('POST','post.php'),setRequestHeader('content-type','application/x-www-form-urlencoded'),
send('content='+parentNode.innerHTML.bold(alert('XSS')))">
</b>
Now, many websites have AJAX libraries available. Think about Dojo, JQuery and many other AJAX libraries that power websites. A good deal of them have functions that we can re-use to make worm vectors even smaller. For example look at the following worm vector I produced:
<b>
<img src="" onerror="with(xhr('post.php')),send('content='+parentNode.innerHTML.bold(alert('XSS')))">
</b>
We now use a function called xhr() which might be present in one of the webpages' library. It might be smaller still because many AJAX libraries have functions for posting data through an XmlHttpRequest. So this vector already reduced itself by utilizing the resources at hand.
here is another theoretical example that adds friends where friend_id is a variable already present in the source or it could be a fixed friend_id of the attacker. It could be anything though, and the addfriend() is a resource function we use to add a friend every time the worm is executed on a page, and injects itself again to the profile of the person who opens the page:
<b>
<img src="" onerror="with(xhr('post.php')),send('content='+parentNode.innerHTML.bold(addfriend(friend_id)))">
</b>
2. There have been voices about detecting XSS worm signatures, but as I show you here, worm signature based detection will be made very hard because of the use of already legitimate resources from the webpage itself. Not long ago the AVG virus scanner rated my site as a page that tried to execute malicious scripts. Of course, this was a false positive because I only wrote the code vectors down for analysis. AVG being signature based, still issued a warning. In this light, it would be near impossible to write proper signatures when we utilize the resources that are available to us.
A second issue, is when the page XSS filters look for signature strings that are known to be used in many XSS attacks. But a problem in filtering can arise when we already utilize the resources at hand because almost no filter will filter it's own resources out. So the danger in blocking your own resources will break the websites' own functionality.
That's why resource availability exploitation -or public code abuse- can be very helpful for attackers, and most likely hard to protect against. Again, do not filter and do not rely on blacklisting. Make sure every user supplied data is properly encoded or escaped so that XSS or SQL injection is not possible anymore. If you want to allow users to modify the markup, you could allow them to only modify BBcode for example which give the same type of rich markup, which is a lot better to protect than verbatim markup insertion.
