Tuesday 13 January 2009

A few insights on Web pay-per-click advertising

Pentru inceput as vrea sa mentionez ca ideea articolului a aparut ca urmare a citirii documentatiei necesare pentru realizarea referatului de la Complemente de Informatica. Aceasta trata, printre altele, si cateva probleme de securitate legate de web advertising, in special cele care afecteaza tehnicile de "click through payment"(pay-per-click), astazi una dintre cele mai raspandite metode de realizare a publicitatii pe Internet.

Pentru cei care nu stiu inca in ce consta metoda (inainte de citirea articolului si eu ma numaram printre ei :)) o sa incerc sa le ofer o explicatie succinta. In linii mari, totul arata cam asa: administratorul unui site T (target site) accepa sa plateasca un alt site R, care ii face publicitate, cu o anumita suma de bani direct proportionala cu numarul de click-uri pe care utilizatorii care intra pe site-ul R il dau pe bannerele publicitare care ii redirecteaza catre T. Prin urmare, "gsp.ro" primeste bani de fiecare data cand tu dai click pe bannerul care te anunta de ultima oferta de la Orange sau de existenta unui showroom now in Bucuresti.

Si aici intervine partea interesanta! Studiile au aratat ca in general, rata click-urilor pentru bannere publicitare este una foarte mica, de doar 1-3%. Pana la urma tu ai vrut sa afli ce a facut Steaua la ultimul meci si nu te intereseaza sa-ti cumperi o combina frigorifica chiar daca aceasta este la incredibilul pret de XXX RON!! Rata fiind atat de mica, si pretul pentru fiecare click este calculat in consecinta. De aceea R este interesat sa produca cat mai multe cereri catre T pentru a-si imbunatati click-rate-ul si poate incerca sa realizeze acest lucru si prin metode mai putin "cinstite".

Cea mai simpla abordare ar fi ca administratorul lui R sa ruleze un program care emite periodic cereri catre T sub forma unui click fictiv. Ideea este insa ineficienta, deoarece, in cele mai multe cazuri administratorul lui T va stipula in contract o clauza conform careia alege sa plateasca doar pentru cereri cu IP-uri unice. Bineinteles, un atacator mai sofisticat poate incerca sa pacaleasca sistemul si de data aceasta, generand cereri cu IP-uri diferite. Metoda presupune un efort suplimentar, este mai dificil de implementat si de cele mai multe ori poate fi detectatata usor de catre T. Si asta deoarece, in majoritatea cazurilor nu va exista nici un browser la celalalt capat al conexiunii care sa primeasca raspunsul lui T. Administratorul lui R nu este interesat de continutul paginii "pageT.html". Iar daca aceasta contine si link-uri catre imagini sau alte elemente HTML, link-uri pe care un browser web le-ar interpreta in consecinta, atunci o cerere pentru "pageT.html" nu va mai fi urmata si de o alta cerere pentru elementele HTML continute in aceasta. Prin urmare, administratorul lui T poate afla daca cererea este sau nu valida si poate lua masuri.

Din aceasta cauza, poate una dintre cele mai utilizate metode de "pacalire" a site-ului target folosite azi este aceea de obligare a user-ului sa aceseze "pageT.html" prin realizarea unei pagini "pageR.html" care sa creasca click-count-ul de fiecare data cand un nou utilizator ajunge aici. In plus, intregul proces poate fi ascuns utilizatorului, care nu va afla niciodata ca este folosit de R pentru a obtine recompense financiare de la T. Dar, chiar daca atacurile sunt sau nu vizibile utilizatorului, si acestea pot fi depistate de administratorul lui T daca acesta hotaraste sa-si inspecteze colaboratorii. Daca admin-ul lui T intra pe site-ul lui R el va descoperii frauda si poate actiona in consecina, rupand contractul cu R pentru a-si cauta un partener mai serios.

Si acum, pentru ca am salvat ce este mai bun pentru final, pot sa afirm ca exista si o metoda de generare a click-urilor fictive care este imposibil de detectat de catre administratorul site-ului target. Metoda presupune existenta unui site suplimentar S cu care R sa colaboreze. Procedeul este simplu si inglobeaza 2 click-uri simulate: in momentul in care un utilizator face o cerere pentru "pageS.html" , S trimite un click fictiv catre R care la randul sau va genera un click pe baza celui primi de la S pe care il trimite lui T. Ultimul click are menirea de a-l pacali pe acesta din urma facandu-l sa creada ca S este sursa cereri => metoda de generare este destul de complicata, dar realizabila. In plus, atacul are si "avantajul" ca face site-urile target susceptibile la "spamming" indirect (daca prin contract R este obligat sa nu foloseasca spamming-ul pentru a-si mari click-count-ul, acum o poate face mascat, prin intermediul lui S. Administratorul lui T nu poate sa demonstreze ca exista o legatura intre S si R si prin urmare nu-l poate acuza pe R de practici necinstite).

Totusi, atacul are si unele "dezavantaje": este complet nefolositor in cazul advertising-ului de tip pay-per-sale (utilizatorul trebuie sa si achizitioneze unul din item-urile expuse la vanzare pe site-ul target) sau pay-per-lead ((utilizatorul trebuie sa aiba activitate suplimentara pe pagina pentru ca click-ul sa fie validat). Si avand in vedere ca siguranta advertisementului de tip pay-per-click poate fi sparta foarte usor, tot mai multi utilizatori isi indreapta atentia catre celelalte 2 metode de publicitate ...

No comments: