Re: Off-topic concerning a web vote debacle

Hi, this is not the solution to the problem discussed below. :-) But I
can descibe what I did as a workaround to controll inputs:

We had a questionnaire only definite people should answer. They got a
password by e-mail. But if you use only a htaccess protection you could
vote more then one time. So I need the password or login in the data set.

Therefor I misused the CASEROUTE function:

  <TEXT NAME="pin"
        CAPTION="Please enter your PIN"
        MAXLEN="8" />
 
  <CASEROUTE SWITCH="pin" DEFAULT="pin-error.survey">
    <CASE VALUE="01020304" CONTINUE="introduction.survey" />
    <CASE VALUE="05060708" CONTINUE="introduction.survey" />
    <CASE VALUE="09101112" CONTINUE="introduction.survey" />
    ...
  </CASEROUTE>


With it user with wrong passwords got a error message and could not fill
out the form. When they guess right the URL of the second page -
introduction.survey - this is no problem, there is no data in the
variable "pin" even if they fill out the survey.

In an final step I purged all data sets with no (or missing entry 999)
in pin and I deleted all multiple data sets - except the last -
identified by the pin.

Clemens



Joel Palmius wrote:
> 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

Skickat av Clemens Gruber <[email protected]>
till survey-discussion