Articoli Manifesto Tools Links Canali Libri Contatti ?
Sicurezza / Web

The Fake Poll [EN]

Abstract
By illustrating the weaknesses of the most part of web polls and with the explanation of some possible solution to this problem, this paper wants to be helpful for all people who don't know how a web poll works, and also for the webmasters who want to place on their website a poll really: "TRUE" and "SECURE"
Data di stesura: 08/06/2004
Data di pubblicazione: 21/06/2004
Ultima modifica: 04/04/2006
di Donato Ferrante Discuti sul forum   Stampa

Introduction

Today is very frequent to see on a website one or more polls like:
        ----------------
       /| Today's Poll |\
----------------------------------
|"What is your favourite O.S. ?" |
----------------------------------
|
o GNU/Linux
|
o Windows
|
o Others
|
|
----------------------------------
|                        [Submit]|
----------------------------------
Normally people has no interest to submit or not submit their choice but sometimes the things may change...

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

The Kinds of Poll

On the web we have a great variety of polls, that can or not adopt stratagems to avoid malicious actions...

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])
[1] s.a.p.i.: server autogenerated password + id
it means that the password and the user id have been assigned automatically by the server using some algorithm.

[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

Each of the above listed methods have one or more limitations/protections that can be bypassed to counterfeit the poll's result.

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

We have nearly finished this section. At this point I will illustrate as a malicious one acts to submit ballot by using "fake" request, this method works without problem with all the "direct submit" methods.

The work is divided in two parts:

1. Get the Info

First of all you must know the essential information to post a valid submit to a web poll. So the simple way to get that info, it's to open a sniffer and to see what is the packet content after a browser submit to the poll.

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
now, we can try to made a new submit on the web poll and this time our request will be not classified valid for the poll... so let's gonna see the "why"...

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
We can note that the poll has stored in the browser cookies' folder a cookie.
In fact in our second request we have the following line:
Cookie: someCookie=aValue
This makes our request not valid for the web poll policy.

2. Craft the Request

We have understood that the browser is not so intelligent sometimes, in fact it's cookized (sorry for the term) in its requests.
So the best way to bypass this limitation is to use an hand-crafted 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
The effects of such a request are:
  1. our submit is ever valid.
  2. we have no cookie problem.

Solutions

The main problem is that all the requests to a web poll that an user makes are visible to the same user.

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.
Remember this is only a base to start to implement or adopt a good poll service for your website.

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.

Discuti sul forum   Stampa

Cosa ne pensi di questo articolo?

Discussioni

Questo articolo o l'argomento ti ha interessato? Parliamone.