Fixing the Problem with Click Websites

Wildhoney · 12-03-2007, 02:11 PM

Perhaps a rather equivocal title there, so let me explain myself. I was referred to a website the other day, entitled Click to the Moon. A novel idea where users click a button based on which continent you would like to see get to the moon first - now, that's all fine and dandy but there's 1 or 2 problems that crop up. Namely, click-bots.

Now, they have modified the website slightly since I was playing with it, which is good in a way as I can release the click-bot that I made for the website and it won't work because it uses get instead of post, and all sorts of other various differences between old Click the Moon, and the one version. Though the problems still very much remain.

The click-bot code is very simple:

php Code:

set_time_limit(0);

for($iIndex = 0; $iIndex <= 2000; $iIndex++)
{
    $pCurl = curl_init('http://www.clicktothemoon.com/clickit.php?continent=europe');
    
    curl_exec($pCurl);
}

Now, to protect against using click-bots, the creator placed an upper limit of 2,000 clicks, and once you reach that amount, you cannot click any more for, well, forever. That's okay, but there are definitely better ways to do it. We have 1 or 2 major problems - all stemming from the logging of the IP address, when limiting people to 2,000:

I could easily modify my click-bot script to add a random proxy based on a pre-compiled proxy array;
If I were on an ISP whose IP changed regularly, such as AOL, then I wouldn't need to add a proxy, I could just keep going and going with the code above.

Article: Why you shouldn't rely entirely on an IP.

But there is a solution! And although we can never protect against click-bots completely, there are some solutions at hand.

One of the possible solutions is a captcha image - they are the ever more difficult image verifications where a user has to enter the code in the image. Good in a way, but definitely bad in the scenario as you want to click and go, instead of being asked to enter image code. Although you could feasibly only provide the captcha image once, but even still, bad usability in my eyes, especially with the images' complexity these days to prevent spam-bots from deciphering them.

We could also keep a close-eye on the time the page was loaded, and then record the time when they click the link - and then set a time-out period to 30 seconds or so. But what if that user goes to make a cup of tea and then returns to click a continent? They're going to get a message which resembles something like: "Your click cannot be registered. Please try again." Bad - surely? You could even add Javascript code to record the time of the button click, and then compare it once the page has reloaded, what if though, the user has disabled Javascript? Although that's only around 6% these days, it's still a huge chunk of Internet users and so not practical.

My solution? Well, my solution is to compile a random finger-print and then store it in a session variable. Of course, for this you can even open up the session ID in the GET variable because security does not matter at all in this scenario. If somebody knows your session ID via fixation or guess-work, who cares? Your click will still be registered successfully. This will also prevents users from emulating a click-bot and to keep hitting F5 to reload the page and thus register a new click. Now, when a user hits F5, they will be informed that their click cannot be registered. Remember though, nothing is 100% fool-proof.

Consider our new form as it appears below:

html4strict Code:

<form enctype="multipart/form-data" method="get" action="index2.php">

    <p>
        <input type="hidden" name="txtFingerprint" value="3e06fc63" />
        <input type="submit" name="bFormSubmitted" value="Click, click" />
    </p>
    
</form>

Note: The value for txtFingerprint in the above example comes from echoing out our session variable:

php Code:

echo $_SESSION['FP'];

We not only have a button, but we have a fingerprint as well. The fingerprint was generated using a short message digest, ADLER32:

php Code:

$_SESSION['FP'] = hash('adler32', mktime() . microtime());

Then all we have to do is check that session variable matches the fingerprint set in the GET variable from our hidden element in the above form. If they match then we're fine, click registered. If, however, they do not match then the click will be deemed an attempted cheat and therefore not registered. Once our first legitimate click has been registered, we will want to clear regenerate the fingerprint in our session - or you could regenerate and work from the session ID itself.

The full code is as follows:

php Code:

session_start();

function doClick()
{
    if(!isset($_GET['txtFingerprint']))
    {
        return false;
    }
    
    if(!isset($_SERVER['HTTP_USER_AGENT']))
    {
        return false;
    }
    
    if($_GET['txtFingerprint'] == $_SESSION['FP'])
    {
        return true;
    }
    
    return false;
}

if(isset($_GET['bFormSubmitted']))
{
    if(doClick())
    {
        echo 'Your click was registered! Thank you.';
    }
    else
    {
        echo 'Your click is invalid.';
    }
}

Now, you've heard the theory, and seen the code, so I am hope this makes sense. Of course, anywhere where you don't want a click to be recorded more than once, you can use this little trick to prevent it. It will stamp out most attempts of crafting a working click-bot - only the most determined will be able to crack it and they can crack it i n3 easy steps, for those interested:

Visit index page;
Extract ID from hidden element;
Query the click page and pass the session ID via the cookie saved.

The more complex you make it, obviously the more time it'll take to craft a spam-bot. No matter what you do though, there will always be a way to get around it, it's just a case of how difficult you make it, and thus is it worth the programmer's time?

Incidentally, you will also notice that I check for an empty HTTP_USER_AGENT, this is because the PHP function file_get_contents, by default, sends a HTTP request without setting the HTTP_USER_AGENT, whereas almost every browser will send a HTTP request with the HTTP_USER_AGENT attribute set. So in order to create a click-bot you will also need to attach a HTTP_USER_AGENT.