How to prevent online survey?

How to avoid multiple votes by robots

[WebDawg]

Hi,

I recently created an online survey for our corporate web site. It was a "which is your favorite team" question, and after a few days it degenerated into a robot-voting frenzy. At one point we were getting something like 50000 votes a day from several robots voting against each other!

In spite of these problems, I have been asked to develop other surveys, perhaps even with a prize drawing for respondants. Is there any way to prevent this kind of multiple voting abuse, or should I just start looking for another job?

Thanks in advance for your advice!

P.S. Sorry about the title of this post, wish I could correct it!

[claus]

Welcome to WebmaterWorld WebDawg :)

You could try to make the vote dependent on accept of cookies. That is - if you don't accept a cookie you can't vote. People who disable cookies won't be able to vote then, but that should do the trick for the SE-spiders.

/claus

[moltar]

Better to do it by IP and cookies. Most likely the same robot will vote from the same IP and once it placed a vote it can't vote anymore.

[webdevsf]

Use one of those tools that show a jpeg of a bunch of letters all tilted. They are pretty decent at keeping out the bots.

[WebDawg]

Thanks for your quick replies!

We did use cookies to keep track of voting (people were allowed one vote per day), but some robots just deleted them and other robots just kept resending a copy of the cookie that made it appear that they hadn't voted yet.

IP tracking would be a solution for the flagrant abusers. However, when I analyzed the logs in an attempt to remove fraudulent votes, I realized that there was also a large number of cases where the same IP was voting more than once a day, but the cause was that these were corporate users behind a firewall/proxy, who all share a small pool of IP addresses when accessing the Internet, as well as dialup users.

The CAPTCHA, or "Completely Automated Public Turing Test to Tell Computers and Humans Apart.", seems like the most reliable method, although even it is not foolproof, as this interesting article demonstrates [coe.berkeley.edu...]

Does anyone know if this kind of "gimpy" program is available in the opensource community or as commercial software?

Thanks again!

P.S. It turned out that the people who programmed these voting robots were employees of the corporate sponsers of the teams! One of them was a bank, for crying out load! You'd think they would know better :-0 And to top if off, they actually complained to our public relations department after we removed their 60,000 or so votes from the results:-(

[moltar]

Well, this is up to you to judge. You either let bots to vote, or few people won't get to vote because they are behind proxy/firewall.

I had the same problem and I chose to go with IP filtering.

[claus]

>> voting robots

ah, that explains some... i thought it was SE spiders.

[jamesa]

What webdevsf said will definitely keep out the bots, which was my initial thought as well. But that won't keep people from voting more than once however. They can still cast multiple votes manually.

If each voter has a their own email address, why don't you create a two-step process: they cast their vote via a form, your script shoots them back an email with a URL containing a unique ID, they visit the URL to cement the vote. It would be very easy this way to filter out duplicate requests from the same email address. If you know the email addresses of all the participants then you could weed out invalid email addresses making it foolproof.

[g1smd]

>> It would be very easy this way to filter out duplicate requests from the same email address. <<

[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]

[jamesa]

ROFL, g1smd! But actually that would still work because that's only half of it. he other half is that they would need to confirm the entry, which is sent to them at the email address they voted with. Since they are using random email addresses they wouldn't get the unique confirmation URL.

1. vote is received
2. voter's email address is checked against company rooster (if available). If it is valid, continue...
3. reply email is sent to voter which includes a unique confirmation URL.
4. voter receives email, visits unique URL to confirm vote.
5. vote is accepted by system.

So steps 3 & 4 prevent people from casting more than one vote per email address (also prevents the use of invalid email addresses), and step 2 rules out people voting with offsite email addresses.

[dmorison]

One line of defence which will help prevent robot form submission via a large network of anonymous proxy servers is to tie your form field names to the users IP address.

There are plenty of ways to do this. If you are using a server side scripting language with an MD5 function, one way is to compute impossible to guess field name values at the top of your script; based on a secret key and the users IP address, for example (in PHP)

$username_field_name = MD5("username"."something_secret".$REMOTE_IP);

Then when generating your form and doing the subsequent processing; simply use $username_field_name instead of fixed values.

$username_field_name is unique (but constant) for every IP; so for an attacker to beat this script using distributed proxy servers they have no choice but to code a bespoke system that studies the contents of a GET operation before submitting a POST operation.

[Iguana]

Am I right in thinking that most bots will just be calling up the voting page directly? How about voting by a form submit() (most bots don't render pages and execute Javascript). Or check the referring page (not foolproof but the variable may not be programmed into their bots).

[jamesa]

Unfortunately it would be pretty easy to have the bot do the POST request itself while sending the form page as the referrer. This is how the popular formmail.pl script got hammered by spammers until the author hard-coded an array of acceptable email addresses into the script itself.