Off-topic concerning a web vote debacle

This is just an interesting story which is spinning around on swedish news 
sites today, added with a mod_survey opinion at the end.

In sweden, the national television has daylight information every friday. 
It's an animated sun which rises with numbers on when dawn arrives at 
three major cities, and then sets with numbers on when night starts. In a 
country as north as sweden this is interesting since dawn and dusk varies 
heavily over the year. In the northernmost city, the sun does not rise at 
all for a period during the winter.

Now, however, the guys at the national television had discovered that the 
three cities were geographically distributed in a rather unbalanced way, 
leaving a large part of sweden without relevant daylight information. Thus 
they started a web poll concerning what city should be added on the info 
to make the geographical distribution a bit better.

To start with this worked rather well, and the local news papers in the 
candidate cities campaigned for getting their readers to visit the web 
poll and vote for their city.

Yesterday the poll was shut down though, since it was discovered that two 
cities were rising drastically on the results, with some 150 votes per 
minute. Needless to say some locals had discovered how to script the 
voting.

This merits some technical analysis. Web votes have lately been gaining 
heavily in news papers: the results are related as facts and complete 
articles are built around them. No heed is taken to the shakiness of the 
underlying technology.

First: the current poll had a uniqueness policy based on session cookies. 
It did not even store the cookies on disk, all you had to do to vote again 
was to restart the web browser. Every single noob and their grandmother 
could figure this out.

Second: No IP-based uniqueness policy was implemented. This is in itself a 
rather logical thing what with NAT and everything.

Third: No overload protection was installed, meaning the system swallowed 
as many hits it could handle per second without protesting.

These things taken together was in practise an open invitation to a 
scripted vote "attack".

So what do you do to avoid these things? In mod_survey, the cookie-based 
uniqueness policy isn't even implemented: there's no point since you can't 
trust anything coming from a client. The uniqueness policies implemented 
are IP-based and authentication-based. Neither would have worked well in 
this scenario.

The best you could have done currently would have been making a login form 
where you have to register with a valid email adress (stored in a 
database) in order to be allowed to vote. This would have been cumbersome 
but secure. It would also be technically feasible with the current 
mod_survey release. It would, however, have resulted in very very few 
votes since no-one would bother to do the whole procedure.

Some day in the future, I will have to address this. My current idea to 
solve the problem is a combination of cookie-based and IP-based policies: 
uniqueness is primarily based on a disk-stored permanent cookie. However 
to avoid scripted attacks, a server-side key would be stored (a hash based 
on the combination of browser string and and the IP number) and which 
would live for, say, ten minutes. Thus the NAT problem would be solved 
(all you would have to do is wait a few minutes before being allowed to 
vote if someone with shared IP and same browser string had voted).

Stay tuned, some day my fingers will itch, and I'll implement this.

   // Joel

Skickat av Joel Palmius <[email protected]>
till survey-discussion