Logování aktivit uživatele a problém zabezpečení vstupu rubrika: Návrh

3 Tomáš Miškovský
položil/-a 25.2.2016

Dobrý den, při dnešní analýze nového modulu pro náš e-shopový systém jsme narazili na zajímavý problém, který bych rád předložil vážené odborné veřejnosti k okomentování a získání jiných pohledů na věc. Děkuji předem za každý konstruktivní komentář.
Máme v plánu vyrobit modul umožňující co nejuniverzálnější sledování a logování chování uživatele, s tím že hlavní myšlenkou je otevřenost do budoucna v otázce CO vlastně sledujeme, podobně jako třeba goals v GA, kde taky není dopředu omezeno jestli je sledovaná akce nákup, registrace nebo třeba použití odkazu callto: na mobilu. Podobně i my chceme otevřenou platformu, kde si teprve v budoucnu zákazníci budou vymýšlet jaké chování svých uživatelů chtějí sledovat. Implementačně se bude jednat o jednoduchý log událostí. Data potřebujeme sbírat na serveru, tam se to jeví jako bezproblémové, ale je/bude určitě potřeba mít možnost sbírat události i z klienta, ať už JS kódem nebo loadem nevidtelného obrázku do příslušné stránky. V každém případě zaznamenání akce do logu aktivit vede na http-request na nějaký handler, který si "udělá čárku". Inspirací je opět kód GA.
Otázky: Jaké vidíte možnosti alespoň bazálního zabezpečení takového handleru proti někomu, kdo bude chtít třeba data znehodnotit konkurentovi, jak moc byste se snažili takovýto vstup do systému ochránít? Počet requestů z jedné IP za jednotku času... Snaha o předání referreru v hlavičce požadavku... Pokusit se o nějaké tokenování... A jak by se změnila situace kdybych si zadal sledovat nejen přihlášené uživatele, ale i anonymní provoz, jako to dělá GA, nebo systémy na heatmapy? A vůbec tuší někdo jak je proti snaze škodit ochráněno samotné GA (nic moc jsem nevygooglil)? Samé otázky :-) Ještě jednou předem děkuji za postřehy.

odkaz
8 Jakub Macek
odpověděl/-a 2.3.2016

Osobně tam moc potenciál na ochránění nevidím. Zkusil jsem totiž postupovat z opačné strany - jak bych taková data znehodnotil. Primárně bych potřeboval vědět nějakou strategii, kterou způsobit škodu. Takže ještě předtím vzniká otázka, co vlastně na základě těch výsledků provozovatel provádí. Pokud bych mluvil ze zkušenosti, tak většina firem nic moc významného. V tomto bodě bude největší potenciál na kreativitu. Pokud někdo jiný přijde s lepším příkladem zneužitelné akce, tak to může změnit ta protiopatření.

Takže dejme tomu, že máme provozovatele přednáškových akci. Na základě klikání na nějaké tlačítko zobrazení kontaktu bude provozovatel webu odhadovat, jak je který přednášející populární a tedy podle toho budou plánovat schéma prezentací. Zneužití je jasné - budu jako přednášející klikat na vlastní tlačítko, takže budu upřednostněn. Jako protiopatření skutečně vypadá nejlépe omezení na IP adresu, protože vše ostatní lze snadno změnit.

Zajímavé by ovšem mohlo být třeba sledování změn trendů. Základní úvaha ze vzpomínek ze statistiky: Náhodné veličiny lze obvykle namapovat na nějaké rozdělení a jako pomocný výsledek je číslo, které říká, jak moc chybná je to aproximace. Pokud bych měl data za časové jednotky 0..9, tak by mi vyšlo jako nejbližší nějaké rozdělení. Když přijdou data za časovou jednotku 10 a nebudou tomu rozdělení odpovídat, tak nastala změna. Tím se otázka posunuje na to, jak detekovat přijatelné změny - nejspíše ovšem informovaným člověkem. Tedy například PPC kampaň na konkrétní produkt může ovlivnit zobrazování toho produktu. Jak ovšem poznat, že někdo došlo k nějaké změně? To asi moc nepůjde, protože pokud jsou čísla dřívejšího průběhu malá, tak to může rozhodit i když to někdo náhodně plácne na svůj Facebook.

Komentáře

  • Tomáš Miškovský : Děkuju za vaše úvahy... já to vidím zatím hlavně tak, že co se z principu na klienta dát nemusí, udělá se na serveru, aby ta díra, když tam už musí být, byla co nejmenší... a zbytek souhlasím. Díky. 3.3.2016

Pro plný přístup na Devel.cz se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.