Ceneje.si - Statiska [stran 4]

#31Da zaključim zgodbo.

Danes so me iz ceneje.si obvestili, da je bila res težava pri njih in je 80 preveč klikov.

#32So kaj povedali kje je bila težava oz. če lahko kar napišejo tukaj... da bodo lahko v morebitnih podobnih primerih še drugi videli vzrok in po možnost imeli možnost hitreje odpravit.

#33Zdravo,

Dejansko smo po tem, ko smo dobili želene loge lahko zadevo primerjali in ugotovili, da je pri teh 80 preusmeritvah prišlo do SQL injection napada na trgovca preko povezav na Ceneje.si. Tip napada je takšen, da se prilagajajo URL-ji, zato smo mi lahko to prepoznali, ko smo s pomočjo loga od OvcaX-a sfilitrirali zadevo.

Žal pa ne vem zakaj se na drugi strani to ni zabeležilo v strežnik. Morda kakšna blokada?

Torej še nasvet po korakih vsem tistim, ki boste imeli probleme z nepričakovanim odstopanjem:

- preverite število, ki je bilo zabeleženo neposredno na vašem strežniku in zabeležite odstopanje (analitika ala GA ni dovolj točna).
- preglejte podroben izpis na straneh za trgovce.
- če imate znanje in malo časa, lahko izpis iz vaše analitike zelo hitro primerjate z našo podrobno statistiko v Excel izvozu. Tukaj bodite pozorni na odstopanja oz. če se pojavlja kakšen vzorec odstopanj.

V primeru, da ne najdete rešitve oz. še ne ugotovite kje je prišlo do problema:
- Pokličite svojega skrbnika in razložite situacijo. V večini primerov boste odgovor dobili še isti dan (odvisno od ure, kompleksnosti in razpoložljivosti prisotjnih v podjetju).
- V kolikor na naši strani ne bomo mogli najti napake, vas bomo prosili, da nam pošljete svoj server log.
- Po pregledu server loga in ugotovitvi(ali ne), vam bomo poslali obrazložitev in v primeru, da je resnično prišlo do zlorabe tudi dobropis.

Zgoraj napisano je postopek, ki se po navadi odvije v teh primerih. Situacije kjer dejansko pride do dobropisa so redke vendar še vedno možne. Večinoma pride do tega zaradi nepopolnega beleženja statistik na trgovčevi strani.
Je pa seveda zgornji postopek odvisen od situacije tako, da se lahko prilagaja in spreminja.

Lep pozdrav, Žiga

#34Nekaj mi ni jasno glede tega "SQL injection napada na trgovca".
Kolikor vidim sam na vaši spletni strani, imate interni redirekt na osnovi ID trgovca in ID artikla (oz. nečesa iz podatkov GET). Torej dejansko je bil poizkus SQL injectiona usmerjen proti vaši strani in s samim trgovcem verjetno nima nobene zveze (torej je verjetno še dosti neutemeljeno zaračunanih klikov).
Kot drugo, če redirect skripti rata validirati input in je prišla do točke, kjer dejansko naredi redirect, bi v zadnjem možnem trenutku morali zabeležiti klik in bremeniti stanje trgovca. Če to tako tudi stori, kako ločite legalen klik od domnevnega "prilagajanja" GET requesta, če je v obeh primerov uporabnik vseeno prišel na stran trgovca?

#35Torej po odgovoru našega IT-jevca se moram malo popravit.
Napad je bil res naperjen proti nam - očitno pa je avtomatika vmes prišla tudi na stran trgovcev. Dejansko imamo dosti načinov da ugotovimo ali je neka preusmeritev legitimna in jo potem zabeležimo, vendar pa se ves čas dogaja nekaj novega zato se prilagajamo sproti. Ko ugotovimo s pomočjo strank, da je do česa takšnega prišlo zadevo potem hitro uredimo.

Kot že rečeno smo s časom razvili precej "checkov", ki izločijo klike v kolikor se oceni, da zadeva ni realna. Se pa ne slepimo s tem, da se to ne more zgoditi. Iz tega razloga vse pritožbe obravnavamo skrajno resno in jih razrešimo. Trgovec to rešitev vidi v dobropisu na naši strani pa sprožimo pravne postopke proti storilcu v kolikor je to smotrno.

Lep pozdrav, Žiga