The sniper
Normal fuzzing is like shooting a machine gun in the dark and having no idea where the target is. You might hit the target a number of times, but you also miss an awful lot, and it takes a lot of rounds. Using targeted fuzzing, on the other hand, is a bit like a sniper observing the targets and picking them off one by one. I prefer the sniper approach because, although you may not get a wide range of results, you will often get more meaningful data and let’s face it, snipers are cool. :)
XSS Filter and the javascript protocol
I contract for Microsoft testing the security of the XSS Filter, which is due to be released soon in the next version of Internet Explorer. Part of this work involves making sure that XSS Filter successfully detects javascript protocol injections in various ways. I saw this as an ideal opportunity to perform some targeted fuzzing to obtain every possible combination.
The first task was to gather as many known inputs as possible, javascript: can be represented in various ways as I’m sure you’re aware of like javascript:, for example. Then you gather any unknown input combinations. So in this case you can traverse the amount of characters from 0 to 65535 or more, and either replace part of the string or add to it. In addition to this, you can also encode the character in different ways as mentioned previously, �  etc. The standard way of performing such a fuzz would be to use iframes because this allows you to execute javascript: automatically, however, I encountered a problem using this method; It’s very slow and takes up too much memory for the amount of data I wanted to test.
Making a targeted fuzzer is about understanding how to achieve your goal in the quickest possible time and finding your targets quickly. To do this, I decided to use the browser to my advantage, when creating links in any browser it is possible to find if that link uses a certain protocol like HTTP and also javascript:. I decided to let the browser tell me if my fuzz was successful. Using normal <A> links makes the fuzzer much faster and it was possible to scan around 10,000 links at once. Using this speed, it was possible to scan characters 0 to 65535, and if they were URL encoded, HTML entities, replace or add in every combination in only a few minutes.
If you found the Javascript protocol fuzzer interesting, the source code can be found here:
http://www.businessinfo.co.uk/labs/javascript_protocol_fuzzer/javascript_protocol_fuzzer.phps
A demo of the final result can be viewed here:-
http://www.businessinfo.co.uk/labs/javascript_protocol_fuzzer/javascript_protocol_fuzzer.php
Logging the results
The protocol fuzzer I described had a huge advantage over traditional fuzzing, because the data didn’t cause a browser crash, it was possible to log all results without any problems. I did this using a standard JavaScript logger, which involves creating a dynamic image in JavaScript and sending the results to a server side script like the following code:
var logger = new Image();
logger.src=‘yoururl.php?link=’+yourdata;
What if your goal is to crash the browser? I came across this exact problem when working on another project for Microsoft. There are two ways to achieve this, one is to log the results before sending the output and the other is to remotely control the target and have the fuzzing code sent to the target. I decided because I was interested in how to crash the browser once with the code I supplied, I would log the results first before sending the output to the browser. You can do this in PHP by using output buffering; other languages may have similar features. Output buffering works by constructing the page before sending it to the browser, this is ideal because you can log the results and then send the data and see what happens. Here is a simple code snippet that I used:-
<?php
function saveCache($buffer) {
$fp = fopen(‘cache.txt’, ‘w’) or die(‘unable to open’);
fwrite($fp, $buffer); // Log the results
fclose($fp);
return $buffer;
}
ob_start(“saveCache”); // Don’t send it to the browser yet
?>
Your fuzz output here
<?php
ob_end_flush(); // Send the output to the browser
?>
Summary
My fuzzer proved very successful and enabled me to perform some rigorous testing on the XSS filter to make sure it detected many javascript protocol injections. Because the code I wrote worked across browsers it also found some interesting cross browser issues which was an added bonus. Here’s a small sample of some interesting results it found in Firefox 2.0.0.14:-
Char: 56320, link: jav�ascript:
Char: 56321, link: jav�ascript:
Char: 56322, link: jav�ascript:
I hope you enjoyed my article and I hope to see you all at BlueHat this October. Happy sniping.
-Gareth Heyes, Independent Security Researcher