While playing around looking for a way to catch xss exploitation on a web application honeypot I've stumbled on the the problem of logging DOM XSS injections performed in the fragment portion of the URL.

As specified by the RFCs browsers are not required to send the fragment to the server since it should be used only for client-side purposes. This is a problem in a scenario where a web app honeypot is involved because we would want to log everything that could expose a potential attack.

Since we can't do much server-side it's still possible to catch fragments trough a little javascript trickery. For example on page load we can silently send via an ajax call the current window.location (and completely delegate the hassle to analyze it to our honeypot, server-side).

And as DOM XSS are heavily conditioned by the client enviroment (browser type, version, etc) we should send these informations alongside the window.location too for a better analysis.

A quick prototype using jQuery:

// Build the request
var request = { 'url': window.location.toString()};
request = $.extend(request, $.browser);

// Send via ajax
$.ajax({
  type: 'POST',
  url: 'http://honeypot/catch.php',
  data: request,
  complete: function(jqXHR, textStatus) {
    console.log('URL Sent: ' + textStatus);
  }
});

I've taken advantage of jQuery.browser to collect browser informations. I put together a simplified proof of concept.

The implementation of catch.php is a matter of choice.

Personally I'd like it more to not send responses back to requests (just throw 404s) to reduce the risk a brute force fuzz might undercover it: it's an honeypot after all! It's like a ninja web app!

The downside of this approach is that without s solid error-checking mechanism our ajax communications are downgraded to best effort attempts.

Anyway I am looking to write a plugin for wordpot to handle this so I might eventually change my mind.