Poll Code Writers Are Lazy and Stupid

update: the title was just in jest so please don’t get too offended anyone =) upon thinking about this problem a little more, the solutions are all rather similar to the solutions for blog comment / social media spam. if you want to be 100% sure a human is voting, then you have to use a moderately strong CAPTCHA. That still leaves you open to unsophisticated human-powered attacks. Read on for one simple, 30-min fix based upon IP restriction per time period.


There you are, a recent college graduate, fresh out of school and working for some giant media conglomerate.

Your boss comes to you with an assignment, assuring you it should only take a few hours or less to “whip something up.” (the dreaded phrase)

You get all of the basic, core functionality complete. But then some smart-ass coworker asks, “what will you do about ballot stuffing?”

Feeling particularly lazy that day, you blow him off and decide to punt on the issue.

Ballot stuffers / “hackers” on teh internets? Lawd knows that never happens!

So you forgo writing any kind of rudimentary multiple vote checking…

Until Today

Adding this is literally about 25-50 lines of code in any language, perhaps more if you want to get crazy with blocking IP subnets / proxy servers.

You might be wondering, what about users sharing the same connection or proxy server? Tough luck for them.

If you don’t limit it to X votes per IP per day/hour/week/whatever, you have just opened yourself up to unlimited “hacking” of your ballot by any coder / script kiddy who takes 5 minutes to view source & write a basic ballot stuffer.

And by all means, if you want to open the voting up to infinite votes per IP address… that’s cool too. Just don’t complain when 5,000 votes come from the same IP.

So… no excuses

Our example “poll_ips” lookup table.

id | poll_id | ip_address   | created_at
-------------------------------------------------
1  | 27      | 65.92.69.215 | 2007-09-04 01:27:16
2  | 27      | 27.39.27.15  | 2007-09-12 22:01:47
3  | 27      | 82.47.45.92  | 2007-09-12 23:10:36

Pseudocode

#IP address is in variable $ip, 24 hours ago from now stored in $day_ago

SELECT * FROM poll_ips WHERE ip_address = $ip AND created_at > $day_ago;

IF any results?
 # YES: do not count the vote, return
ELSE
 # Check Banned IP Subnet / Proxy Server List
 IF in a banned IP subnet / proxy server list?
   # YES: do not count the vote, return
 END
END

IF we get here, we're all good.
  # DO IT -- count the vote like we normally would... and:
  # Insert the voter's IP address into our "poll_ips" table:
  INSERT INTO poll_ips ('poll_id', 'ip_address', 'created_at') VALUES ($poll_id, $ip_address, CURRENT_TIME())
END

And PAZAAAM, you’ve got a less hackable voting system in about 30 minutes of work.

You now proudly boast on your blog, “Ron Paul supporters, bring it on baby!” :)
Real-live Rails code…

If pseudo-code is not your thing, here is some real live Rails code (slightly adapted for this example) that I use in production:

stat_log = StatLog.find(:first, :conditions => ["ip_address = ? AND DATE_SUB(CURDATE(), INTERVAL 1 DAY) <= created_at", ip_address])
# Only log it if we haven’t seen them before in 24 hours and they have a valid referrer
if (stat_log.nil?) && (not referrer.nil?)
	content_item_id = nil
	StatLog.create(:content_item_id => content_item_id, :ip_address => ip_address)
end

7 Responses to “Poll Code Writers Are Lazy and Stupid”


  1. 1 tante Oct 16th, 2007 at 6:14 am

    I’ve written a reply here.

  2. 2 Mark Coleman Oct 16th, 2007 at 2:25 pm

    So how do you deal with the common scenerio of having multipul users with the same ip address? Wouldn’t everyone after the first person be blocked from taking the poll? Also, what about isps that reassign ip addresses?

  3. 3 Shanti Braford Oct 16th, 2007 at 2:33 pm

    Hey Mark, first - thanks for stopping by.

    I addressed that above, and the answer is yes.

    Perhaps the ideal scenario would be to limit to X votes per IP per block of time.

    It really depends upon the sample size you’re expecting. For a poll in the low thousands, there is a very small chance of any problems.

    I’ve experienced firsthand working at a large Fortune 500 company where a group of individuals decided to game an online poll. We had a large IP subnet space at our disposal and my coworkers literally flooded the results with 1,000s of votes, all without the use of scripting techniques.

    This is not the desired input from the average poll taker. Just like SPAM, there will be dolphins caught in the net of almost any solution you might take. For me, I’d rather stop 95% of sharks with a .01% chance an odd dolphin gets caught in my net.

  4. 4 JimDesu Oct 24th, 2007 at 5:47 pm

    Almost: this will make you think there are stuffing attacks when you get multiple voters behind the same NAT.

  1. 1 I wanna spend all your money... Trackback on Oct 16th, 2007 at 6:18 am
  2. 2 Having a Hackable Online Poll vs. Ensuring Every Single Last (fraudulent or not) Vote is Counted | On Web Apps Pingback on Oct 24th, 2007 at 6:14 pm
  3. 3 13-Line Shell Script Votes for Mr. Splashy Pants 100s of Times | On Web Apps Pingback on Nov 28th, 2007 at 12:09 am