Zabezpečení dat webové aplikace před crawlingem rubrika: Návrh

3 iguana007
položil/-a 29.8.2014

Ahoj,
dorazil mi od klienta požadavek, který zněl cca takto:

Jsme nuceni vyhodit jednoho z našich zaměstnanců, ale ještě nějakou dobu pro nás bude muset pracovat externě. Takže mu povolíme přístup pouze do některých částí systému, ale zároveň by jsme potřebovali zabezpečit systém tak, aby pro něj nebylo jednoduché stáhnout data z naší databáze. Co se týče oprávnění, tak by měl mít povoleno pouze vkládat nové záznamy a prohlížet si ty stávající.

Nyní k systému - jedná se o webovou aplikaci (napsáno v Nette) postavenou na míru pro castingové agentury, takže obsahuje tisíce záznamů o hercích a komparzistech - tj. poměrně detailní osobní informace vč. několika fotografií ke každému z nich.

Co se týče zamezení přístupu do vybraných sekcí/akcí v backendu, tak to není problém, to jsem měl nastaveno za chvíli, díky zabudovanému ACL.

Jak ale ošetřit to, aby tam daná osoba jednoduše nespustila nějaký crawling tool a komplet databázi si nestáhnula k sobě do počítače, byť v surové HTML podobě - nebo si nenapsal skript, který si z DOMu vytáhne jen to potřebné?

Napadlo mne několik řešení, jak to alespoň ztížit, ale zcela to ochránit to asi nepůjde:

  1. Záznamy nezobrazovat na základě jednoduchého ID záznamu v URL /people/detail/XY - toto jsem již změnil na osolený hash, takže incrementální načítání URL již provést nelze
  2. Seznam záznamů se dá prohlížet pouze pomocí javascriptového datagridu, který načítá záznamy na základě scrolování v něm (tj. nedisponuje stránkováním) - zde by mohl být snad jen problém v tom, jaké URL si datagrid volá, pro načtení dalších záznamů - tj. volá si URL, kde je uveden požadovaný offset - tady mne napadlo přidat hashování tohoto offsetu, aby se do této URL nepředávalo jen obyčejné číslo
  3. Detekce User-agenta - v agentuře používájí pouze Firefox a Chrome browsery, ale toto nejpíše nebude problém nasimulovat v crawl toolu, ani příp. custom skriptu, takže mi to přijde jako zbytečné

Dále už nevím, proto bych se vás rád zeptal na vaše návrhy, jak to ještě jinak zabezpečit?

Komentáře

  • roman.hocke : Pokud ta webová aplikace slouží jen pro lidi "zevnitř", co takhle všem "zasvěceným" nastavit ručně nějaký tajný cookie a ten na serveru kontrolovat? — 29.8.2014
  • Anonym : Najväčší fail je v tom, že sa robí nad produkčnýmí dátami. — 29.8.2014
  • VirtualSkiper : Ten napad s "kolackem pro vybrane uzivatele" (aka Token chudeho muze) od @roman.hocke se mi libi. Nic co tady ted vymyslime nebude na 100%, tohle je alespon levne a snadno se to implementuje. — 29.8.2014
  • iguana007 : @5o - je to člověk, který tu databázi plní + občas potřebuje nahlédnout do existujících "karet" komparzistů - takže jaká data než produkční by měl ten člověk vidět? Předpokládám, že se bude jednat pouze o chybějící info o tom, že daná osoba není programátorem, ale uživatelem. — 31.8.2014
  • iguana007 : Děkuji všem za názory, rady, tipy - upravil jsem trošku to ACL, aby nešlo moc rychle provádět ty akce na zobrazování uživatelských dat + přidal jsem vodoznaky ke všem fotkám + jsem tam přidal tu cookie a víc už to asi nemá smysl řešit, jak už tady i zaznělo, tak kdo to bude chtít vykrást a bude mít do systému přistup, tak to udělá vždy, šlo jen o to mu něco takového max. znepříjemnit. — 31.8.2014
odkaz Vyřešeno
8 Jakub Macek
odpověděl/-a 29.8.2014

Aktuálně mě jako nejlepší napadá omezit počet požadavků, které může uživatel za určitý čas provést, na počet odpovídající standardní ruční práci. Sice to není řešení, ale alespoň znepřijemnění.

Spíš přidám jednu položku do seznamu hrozeb - crawling pomocí prohlížeče. Pro ilustraci: potřeboval jsem zjistit v ovládacím panelu Plesk expirační datumy všech XXX hostingu a Plesk se chová poněkud AJAXově, takže vzdoruje klasickému crawlingu. Tak jsem si napsal miniaplikaci pomocí WatiN. Přihlášení provedu ručně a pak to hezky jede samo. Implementace a vyladění trvalo kolem hodiny, takže pro programátora nic zásadně obtížného.

Komentáře

  • Augi : Příp. bych ještě přidal sleep(1000) při renderingu stránky - to by dále znesnadnilo tahání dat. — 29.8.2014
  • onelook : Sleep při renderingu prakticky nic neřeší. Grabuje se obvykle v mnoha paralelních spojeních (pokud jde o čas) a pak tím maximálně zabereš více prostředků serveru, když uživatel nastaví větší stupeň paralelizace, aby graboval vesele dál rychlostí, kterou si to představuje. Bude ti tam totiž viset více otevřených spojení a rozpracovaných požadavků. Maximálně dříve narazí na nějaký technický strop, ale v tom případě ti typicky zahltí server a nebudou jej moci používat ani ostatní. Když už, tak by bylo třeba udělat omezení na uživatele (nikoli session), tedy např. zamezit paralelnímu zpracování požadavků. — 30.8.2014
  • Augi : Příště to chce pozorněji číst - psal jsem, že bych to jen přidal k navrhovanému řešení (které obsahuje omezení na počet požadavků). Takže sleepovat bude jen jedno zpracování requestu (ostatní requesty vypadnou hned na začátku na omezení počtu requestů). — 31.8.2014
  • onelook : Četl jsem myslím pozorně - "omezit počet požadavků, které může uživatel za určitý čas provést". Tedy omezím, že uživatel může provést např. 100 požadavků za minutu. Pokud tam bude sleep, tak provedu 100 požadavků za minuté také, ale nikoli sériově, protože to bude trvat minimálně 100 * 1 s = 100 s jen na tom sleepu (+ nějaká režie přenosu, běhu skriptu apod.). Takže budu stahovat ve dvou "vláknech" a to už nejspíše 100 požadavků za minutu dám (pokud ne, zvýším stupeň paralelizace). A jaký je výsledek? Stáhnu stejné množství dat za daný čas (dle nastaveného limitu) nezávisle na tom, zda tam sleep bude či nikoli. Jen v případě sleepu si tím zaberu více prostředků serveru. Co myslím tím, že "sleepovat bude jedno zpracování requestu", nechápu. Budou snad sleepovat všechna zpracování reqestů v rámci daného limitu. Ty, které se nevejdou do limitu jsou celkem nezajímavá - pro grabujícího nemají užitek (server data nevrátí) a serveru max. zabírají prostředky. — 31.8.2014
  • Kilmar : Ak tieto dáta dokáže zobraziť v prehliadači myslím neexistuje spôsob aby sa to nedalo zcrawlovať. Ani sleep ani obmedenie requestov nieje prekážka. Ja to robím tak, že si spravím threadpool a každému pridelím vlastný interface s vlastnou IP a potom jedniným obmedzením je počet dostupných IP. Dá sa tomu pekne zabrániť ak automaticky vyblokuješ IP, ktorá spraví urćitý počet requestov v nejakom časovom intervale. Je možné, že tým vyblokuješ niekoho nevinného, ale ako vravím, ak je to účelový crawling, takže ten čo crawluje ma k dispozícii mašinu a zdroje tak ho takto vieš rozumne vyblokovať. — 5.9.2014
  • Augi : Vzhledem k tomu, že tazatel ve své otázce zmiňuje ACL, tak jsme všichni předpokládali samozřejmě omezení na počet requestů pod daným uživatelem (pak nějaké další omezení na IP adresy nedává smysl). — 6.9.2014

Pro zobrazení všech 6 odpovědí 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.

Aktuální otázky v rubrice Návrh

Otázky uživatele iguana007