The Java Hacker – Peter Jaric's Blog

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.


The Sea Surfer – a Simple Tool for CSRF Vulnerability Detection and Proof-of-Concept Creation

Lately I have taken an interest in web application security, as covered by OWASP. One common vulnerability in web applications is to be sensitive to CSRF attacks. I have made a small tool in the form of a bookmarklet to detect CSRF vulnerabilities and create proof-of-concept exploits. It is very simple, but it does the job. There will probably be cases when it doesn’t work, but mostly it should. I guess there are similar tools out there already, and you can do this with Firebug for example (albeit that is a bit more cumbersome), but make not mistake: I’m in it for the code.


  • Add the jQuerify bookmarklet to your bookmarks (go to Learning jQuery to find it)
  • Add the Sea Surfer bookmarklet to your bookmarks (by dragging it to your bookmarks bar, for example)

Why do you need to install jQuerify? I was a little lazy and used jQuery in the code, and when I tried to use a jQuery Bookmarklet generator (that would include jQuery for me), Firefox blocked the popup. I am not exactly sure why, but it may have to do with that the call doesn’t seem to originate from the click on the bookmarklet.

How to use

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

An iframe will open and the form will be added to it. It will be submitted automatically. If the submit succeeded, 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

I have more or less hacked this together. Do not expect the highest code standards. Please modify it anyway you want to, though. Then make a bookmarklet of it, with a bookmarklet generator if you want to. I used the Bookmarklet Crunchinator. In the bookmarklet I’ve base64 encoded the code to be able to include the bookmarklet in this page (it broke the page layout, and I may have spent more on trying to fix that than on the code itself). This is not necessary if you convert the code to a bookmarklet yourself and just put it in your bookmarks.

    if (typeof jQuery === 'undefined') {
        alert('Run jQuerify first!');
    } else {
        var w =;
        var body = jQuery(w.document.body);
        jQuery('form').each(function(i) {
            var clone = jQuery(this).clone();
            var inputs = clone.find('input,textarea,select');
            var area = jQuery('<textarea id=\'area' + i + '\' cols=120 rows=50>');
            var desc = '<h1>Form ' + i + '</h1><p>Edit the values and click \'Test vulnerability\' to try it out.</p>';
            var script = 'javascript:function insertAfter(newChild,refChild){refChild.parentNode.insertBefore(newChild,refChild.nextSibling);} var area = document.getElementById(\'area' + i + '\'); var iframe = document.getElementsByTagName(\'iframe\')[0]; if (!iframe) { iframe = document.createElement(\'iframe\'); insertAfter(iframe, area); }  iframe.contentDocument.write(area.value);';
            var a = document.createElement('a');
            a.href = clone.attr('action');
            clone.attr('action', a.href);
            area.text(clone.wrap('<div>').parent().html().replace(/>/g, '>\n') + '<script>document.getElementsByTagName(\'form\')[0].submit();</script>');
            body.append('<br/><input type=submit value="Test vulnerability" onclick="' + script + '"/><br/>');

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


I noticed that there was a quite big short-coming in my code: I only included inputs in the forms, not textareas or selects. This is now fixed.

Meeting Notes #1

I often draw something when I attend meetings at work. It helps me concentrate and it’s fun. I’ll upload some of these drawings here. Here’s the first one:

Fun with JavaScript: count parentheses

Yesterday, I wrote a JavaScript function that returned another function. At one place I wanted to call the returned function immediately, resulting in code looking somewhat like this:


When seeing that code, I asked myself: would it be possible to count the (pairs of) parentheses? After tinkering a bit, I first came up with (as much whitespace as possible cut away to make it fit into a tweet):

function c(a){function b(){return c(arguments.callee.count)};b.count=1+~~a;return b;}

Then I removed the unnecessary use of arguments.callee:

function c(a){function b(){return c(0-~a)};b.count=0-~a;return b}

Finally I wanted to replace the function name c with something looking like a pair of parentheses, and with the help of Mathias Bynens (@mathias) and Gareth Heyes (@garethheyes) I arrived at this:

function ᑕᑐ(a){function b(){return ᑕᑐ(-~a)};b.count=1-~a;return b}ᑕᑐ.count=1;

After running that code, it is now possible to do (this is from the Firebug console):

>>> ᑕᑐ.count
>>> ᑕᑐ()().count
>>> ᑕᑐ()()()()().count

Yes, I know, ᑕᑐ doesn’t really look like parentheses…