The Fake Poll [EN]

Introduction

        ----------------
       /| Today's Poll |\
----------------------------------
|"What is your favourite O.S. ?" |
----------------------------------
|
o GNU/Linux
|
o Windows
|
o Others
|
|
----------------------------------
|                        [Submit]|
----------------------------------

In fact someone, like a malicious one can counterfeit the poll result by using some tricks.

The Kinds of Poll

I will list the most common way to implement a web poll:

• a. direct submit
• b. direct submit (cookie)
• c. direct submit (browser check)
• d. managed submit (user authentication s.a.p.i [1])
• e. managed submit (user authentication u.p.p.i [2])

[2] u.p.p.i.: user personal password + id
it means that the password and the user id have been choosen by the same user.

We have five main kinds of poll:

a) direct submit, the user can submit his ballot by connecting to the web site without any type of authentication.

b) direct submit with cookie, as point a. but after user submit a ballot a cookie will be stored in the user's browser cookies' folder.

c) direct submit with browser check, this is a very strange check that the poll makes on the user's browser request.

d) managed submit s.a.p.i., the user before submit one ballot wait to receive a valid user id and password from the server after that he can express his preference.

e) managed submit u.p.p.i., the user get access to poll after an authentication, based on his personal password and user id.

Limits

We will see, before for each of those their limitations and after I'll describe how a malicious one acts to make "fake" submit.

Well, we can start from the top...

a) direct submit, too easy, an user can simply submit multiple ballot by refreshing his browser, or just clicking on the submit button a lot of times. As you can see this is a very stupid method to manage a web poll!

b) direct submit with cookie, as point a. but after the first submit the user must, delete the stored cookie before submit a new ballot.

c) direct submit with browser check, this method uses the point b. method and have the point b. limitations, but has an additional check to avoid (sure?) superficial kinds of auto-submit program.

d) managed submit with s.a.p.i., this methods seems at first sight useful... but it isn't, in fact it's possible to discover the algorithm that the server uses to autogenerate the couple: password + id, and so is possible to avoid this kind of protection. Sometimes this is possible, by seeing some number of valid couples (password + id). So pay attention to the algorithm that you use!!

e) managed submit with u.p.p.i., the server asks the users to authenticate himself before submit any ballot. After that, the poll may adopt one or more additional methods listed below. Here the limitation is in the "user". Why?
I will answer by observing the following two cases:

1. You must have an account to submit your ballots. But anyone can for example get a fake account and gain access to the poll.
2. The access is limited to a little number of people.
   This is a little more difficult than the illustrated below. In fact a malicious one may have access to sensible personal informations like password and id, but this is possible by using social engineering or with some sniffing section.

Fake submits

The work is divided in two parts:

1. Get the Info

Now we will consider the case that our web poll stores a cookie in the cookie folder.

Well if we see the first request it will be something like:

POST /poll/myChoise.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpg, */*
Referer: http://localhost
Accept-Language: en
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0
Host: localhost
Content-Length: 34
Connection: Keep-Alive
Cache-Control: no-cache
- - -
Poll=Choise0&Submit=someOtherThing

The answer is in the packet sent from our browser:

POST /poll/myChoise.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpg, */*
Referer: http://localhost
Accept-Language: en
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0
Host: localhost
Content-Length: 34
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: someCookie=aValue
- - -
Poll=Choise0&Submit=someOtherThing

2. Craft the Request

For example we may send a valid "fake" request like:

POST /poll/myChoise.php HTTP/1.1
Host: http://localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 34

Poll=Choise0&Submit=someOtherThing

1. our submit is ever valid.
2. we have no cookie problem.

Solutions

It is necessary to adopt a valid method of protection and I think that a good idea may be the following:

1. Users' authentication (with u.p.p.i. method).
2. Server side cookie storage.

Informazioni sull'autore

Donato Ferrante, classe 84. Programmatore e bug-researcher. Il suo sito web è: http://www.autistici.org/fdonato/

È possibile consultare l'elenco degli articoli scritti da Donato Ferrante.

Altri articoli sul tema Sicurezza / Web.

Risorse

1. Italian version of this paper.
   http://www.siforge.org/articles/2004/06/21-the_fake_poll_ita.html