Přesunuto: Implementace ochrany proti robotům

Jakub Šulák

Z forum.php7.org sem přesunu část problému, který začal směřovat do nette (příspěvky ve fóru).
Jde o to, zda (a jak) řešit problém útoku robotů na formuláře.
Zda by nebylo dobré na nějaké nižší úrovni řešit opakované přístupy od dané IP, na kterou by pak následně bylo možné reagovat (blokování přístupu, nemožnost odeslat formulár, přidání formulářového prvku (například captcha)).

Dávám tedy na podmět pmg k diskuzi, jak by tahle ochrana mohla vypadat.

Jod

Najlepšia je asi captcha.

Ondřej Brejla

Spojená s implementací přes JS a automatické doplňování…pokud má uživatel JS zapnuto, je to transparentní a žádná captcha uživatele neobtěžuje, pokud má vypnuto, zobrazí se captcha.

Editoval Warden (19. 1. 2009 13:41)

Jakub Šulák

No teď jde o to, zda by nebylo lepší ověření robota mít v nižší vrstvě, tak aby se to neřešilo na úrovni Captcha komponenty (ta by měla pouze využít toho, co nižší vrstava provede za kontroly).

Jde o tohle:
Pro kontaktní formulář je asi nejlepší zvolit Captcha s JS. Ale například pro fulltextové vyhledávání už je lepší nějaké omezení – pokud někdo vyhledává často (desítky dotazů za minutu), zakážu mu vyhledávat.

Toto jsou samozřejmě věci, které se dají řešit na vyšší úrovni manuálně, ale myslím si, že pokud by se udělalo nějaké základní řešení na nižší úrovni, na kterou by pak presenter jen reagoval nějakou akcí, bylo by to velké usnadnění. Zároveň by nijak tohle řešení nebralo nic na obecnosti nette.

David Grudl

Asi úplně nejlepší je kombinovat několik technik. To znamená na low-level kontrolovat IP adresu, jestli počet requestů nepřekročí určité limity (kontrola může proběhnout „brzy“ a server se tolik nezatěžuje), na vyšší úrovni zabezpečit formuláře (třeba captchou, kterou by však, jak tu bylo napsáno, měl umět vyplnit JavaScript, nebo Akismet) a na nejvyšší úrovni uvažovat nad kešováním častých dotazů a podobně.

Jakub Šulák

jo, s tímto přístupem souhlasím.
Myslíš, že tu low-level kontrolu budeš moci implementovat do některé z dalších verzí nette?

David Grudl

To je myslím spíš úkol pro aplikaci, než framework. Kód, který by měl přijít do bootstrap.php

onge

Pokud jde o to automaticke vyplneni javascriptem, tak si myslim, ze to je dira, kterou by se dalo pouzit k utoku – i kdyz robot nebude umet js interpretovat, tak si muze nejakym zpusobem vyparsovat co ze se to tam ma doplnit a nemusi vubec analyzovat obrazek (minimalne me nenapada, jak dostat do javascriptu informaci o tom, co se ma doplnit, aniz by tohle neslo)

Asi to pomuze proti nejakym obecnym zmetkum, ale proti specializovanemu skriptu ne.

Jod

Napríklad to dočítaš ajaxom tam.

onge

To uz mi prijde trochu prekombinovane. Navic, jak server pozna, ze ten request na vraceni spravneho kodu poslal javasript a ne robot?

Jod

No veď to sa zistiť nedá, že požiadavok poslal robot, keby to šlo neriešime takéto problémy.

onge

Tak potom nechapu, co resi docitani ajaxem. Pokud chci automaticky doplnovat kod javascriptem, musim ten kod uz mit, nebo si ho musim dotahnout tak, ze poslu dotaz na server. Stejne tak ten dotaz muze poslat robot a kod si vytahnout.

Proste dat si captchu a pak si ji skriptem vyplnit mi prijde jako narame slozita operace, ktera nic neresi (protoze to same, co delam ja javascriptem muze udelat robot)

paranoiq

možná by bylo lepší použít na dotyčný js kód nějaký obfuskátor a tím útočníkovi práci se zjištěním kódu k obrázku trochu zkompikovat. navíc to že dnes běžné spamboty neumí js je jen dočasný stav. bude hůř

(extrémní příklad obfuskace js je třeba virus, co teď řádí a přepisuje přes ftp účty napadených jejich weby. jeho javascriptový ‚frontend‘ je zašifrován funkcí, která pro dekódování používá checksumu sebe sama)

Wosonj

Jestli to je kriticka aplikace a je pravdepodobne, ze ji nekdo bude hackovat, tak nic jineho nez kvalitni captcha nepomuze. Doplnovat ji javascriptem, klidne i s obfuscatorem mi prijde drbani se pravou nohou za levym uchem. Proc tam tedy ta captcha vubec je?

Jestli je aplikace relativne hloupost typu nejakeho pridani commentu, bohate postaci kolonka ve formulari „Zadej aktualni rok“ nebo neco takoveho. Stejne tak se da javascriptem do skryteho inputu vlozit vysledek nejakeho vypoctu.

Z metod neobtezujicich uzivatele k plne spokojenosti pouzivam system s 1×1 obrazkem, ktery ulozi do session hodnotu „nejem robot“. Po odeslani formulare pak staci zkontrolovat, ze v session neco takoveho je. Nepotrebuje to javascript a obrazky a session snad jedou vsude.

Jakub Šulák

To si myslím, že je špatná úvaha – „Jestli to je kriticka aplikace a je pravdepodobne, ze ji nekdo bude hackovat, tak nic jineho nez kvalitni captcha nepomuze.“. V podstatě jakoukoliv Captcha ochranu mohu robotem obejít. Dělám-li tedy útok přímo na určitý server, dokážu vždy Captcha obejít.
Podle mě je spíš potřeba diskutovat nad ochranou aplikací před tím, aby jeden uživatel (robot) nespouštěl skript v X instanacích, což by mohlo vést k pádu serveru, případně zpomalení pro ostatní uživatele.

Pokud mi dvakrát za den nějaký robot pošle spam, tak tento robot neútočí na server. Na něj povětšinou stačí jakákoliv Captcha, která není použítá všude (tak aby ji neznal – nikdo se nebude dělat pro váš web s úpravou robota, aby vám něco poslal přes formulář). Navíc existují anti-spam filtry.

Když mi ale někdo bude fulltextově vyhledávat na webu 100× za sekundu, tak nikdo jiný nebude moci web používat (s nadsázkou). A dávat captchu na vyhledávání, to asi ne.

David sice psal, že toto je věc aplikace, ale podle mně by bylo dobré udělat již nějakou low-level kontrolu, zda nějaká ip nepoužívá příliš často určitou službu.

úvaha:

omezím se na to, že služba (akce, skript) na webu je pouze nějaká url (pripadne i GET form), nebo formulář POST – pouze formuláře generované nette
kontrolu provádím pro jednoduchost tak, že mám nějakou „cache-able“ strukturu, ve které mám informace o používání určitých služeb nějakými ip.
pokud ji budu provádět na úrovni aplikace, tak musím u každého formu zavolat obslužnou metodu, která provádí tu správu stavu. U url adres by se asi dalo řešit zavoláním na začátku aplikace.
proč dělím formuláře a url – na url mohu reagovat v podstatě vždy stejně – načetl za minutu stokrát – block. na formulář mohu vypsat captcha a až poté třeba block.
predpoklad: ip adresu utocnik nemeni – z me zkusenosti ji meni, ale ne tak casto (nema vetsinou dostatek moznosti), aby na to bylo nutne brat ohled.

Myslím, že řešit pro url je možné na úrovni aplikace, ale pro formuláře mi přijde nejvhodnější integrace přímo do form třídy (tak aby form nabízel možnost reakce a nastavení po kolika načtení má přijít akce.
A pokud bych něco měl implementovat do základního kamene, jakým je Nette/Forms, tak bych měl integrovat něco, co je logicky pod ním, nikoliv nějakou vyšší součást aplikace.

Sorry za dlouhé vykecávání, jen přemýšlím nahlas. Rád si poslechnu na tohle vaše názory. Před asi půlrokem jsem totiž dost bojoval s problémem útoků na jeden server – a byl to fakt děs to ručně implementovat.

Wosonj

Plácáš páté přes deváté. Pleteš si dvě věci – ochrana před zátěží (třeba DDOS) a test, jestli komunikuješ s počítačem nebo fyzickou osobou.

Ochranu před zátěží je podle mne chybné řešit přes Captcha – to si vyřeš někde low level, aby to fungovalo na všechno. Je úplně jedno, jestli ti přijde 1000 requestů / sec na vyhledávací skript, nebo na nějaký jiný dokument, případně třeba jen obrázek. Na to určitě existují něšjaké moduly do Apache, myslím to mimo jiné zvládá také démon fail2ban. Funguje to tak, že IP s nadměrnými požadavky prostě přidá na nějaký čas do iptables (firewallu).

Test na to, že komunikuješ s člověkem uděláš jedině tak, že chceš odpověď na otázku, kterou program obtížně zodpoví. Jistě, naprogramovat se dá téměř cokoliv, ale některé úkoly jsou extrémně složité (rozuměj drahé). Mezi ně patří například rozpoznávání objektů v obrázku. Existuje na to mnoho metod z oblasti AI, z těch relativně účinných a obecných například neuronové sítě, ale stále neexistuje nic, co by se dokázalo byť jen přiblížit lidskému mozku. Stačí se podívat, jak fungují třeba OCR systémy. Pokud je text v Captcha dobře zdeformovaný, jsou všechny algoritmy prostě k ničemu.

Jakub Šulák

téma jsem založil právě na diskuzi o ochraně proti robotům, nikoliv o testu „člověk vs. robot“
není rozhodně jedno, zda někdo podává request na obrázek, nebo fulltextové vyhledávání – request na obrázek mi může apache ochránit, request na vyhledávání může být závadný i 10× za minutu – a to ti žádný apache v konfiguraci jak je na hostingu nevyřeší.
psal jsem že se to nedá řešit přes Captcha – jen že v určitý okamžik to může být jedna z věcí, která může být reakcí.

ochrana před zátěží na low-level – Bingo! to právě chci :-) Jen jsem chtěl prodiskutovat zda někdo nemá zkušenost s obecnou implementaci, potažmo zda by takováto implementace nebyla dobrá přímo v nette

PS: K poslední větě bych dodal, všechny algoritmy za rozumné náklady ;-)