Joel Palmius
2008-03-14 12:27:13 UTC
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 <***@miun.se>
till survey-discussion
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 <***@miun.se>
till survey-discussion