PHP fórum

Díky za odkaz.

No, já osobně jsem zatím nebyl nucen captchu někde použít

Nejlepší je se jí vyhnout, ale někdy ne, třeba u emailového formuláře. Také je dobré měřit frequenci požadavků, a když máš podezření na robota, teprve captchu aktivuješ.

Určitou alternativou je třeba hashcash. Jestli to neznáš, klient musí najít řetězec se stanoveným prefixem, jehož hash bude začínat několika nulami. Je to ale celkem slabá ochrana a moc to nepotěší uživatele různých mobilních zařízení. JavaScript je navíc na počítání hashů dost pomalý.

Také jsem zjistil, že v javaskriptu NENÍ pořádná implementace SHA. Ta jedna stará, co se používá, nedokáže zpracovat UTF, a jiné, co to dokáží, jsou zbytečně komplikované. A proč to říkám? Napsal jsem si vlastní pro MooTools a musím se pochlubit. Klidně se i podělím. Takhle se dá přenášet heslo přes http a nikdo ho nezjistí. Musí se ale použít hned dva salty, jeden uživatelův osobní a druhý pro každý požadavek. Výsledkem je absolutní ochrana hesla. Proč to píšu?

Určitě to stačí, ale ne proti přímo mířeným útokům…

Tak obávám se, že proti přímo mířeným útokům pomůže jen zablokování IP přímo-mířícího,

Útočník ale IP může měnit několika způsoby:

1. Použitím neveřejných proxy. Dá se sehnat jejich seznam, který je pak ale potřeba aktualizovat. Abych neomezoval běžné uživatele, je vhodné v tomto případě použít captchu.
2. Pomocí skrytého formuláře na nějakém webu. Tady je ale captcha také vhodným řešením.

Chce to vést statistiky jak globálně, tak podle IP a v závislosti na situaci buď vyžadovat test, složitější test (a třeba dobu uměle prodloužit pomocí hashcash), nebo akci dočasně zakázat.

Pokud se najde někdo, kdo bude mířit přímo proti Tobě, buď si dá záležet a najde nějakou chybku v aplikaci,

Nebo také nenjade, když použiju Nette ;-)

popř. např. v nastavení serveru

Dobře, ale chyba v nastavení se dá napravit, aby se útok neopakoval.

Jinak díky za reakce.

Pořád jsem čekal, jestli se někdo neozve, že už se tím zabývá.

Myslím, že jsme se ještě nedohodli na jmenných konvencích pro Nette extras, takže zatím jen předběžně.

Třída by asi dědila FormControl. Měly by jít nastavit parametry pro generování obrázku: formát, font ap. Samotné obrázky by se nejspíš ukládaly pod document root, aby šly linkovat přímo. Další data by nebylo nutné uchovávat. Jméno obrázku by se získalo třeba jako sha1($id . $code), přičemž $id by se poslalo ve skrytém poli a $code by musel uživatel opsat. Na serveru by se jen ověřilo, zda takový obrázek existuje a zda není moc starý. (Takové by odklízel garbage collector.)

Tato metoda má nevýhodu, že podle jména souboru je pro kratší kód velice snadné nalézt odpovídající řetězec hrubou silou. Pro uchování kódů by tedy bylo lepší použít jmenný prostor keše. (Obrázky by potom byly pojmenované jen podle $id.)

Environment::getCache('Nette.Extras.Forms.Captcha');

Každý kód by se musel uložit jako zvláštní položka keše, aby byla jakž takž zachovaná integrita dat. Šlo by tak ale využít možnost otagovat položku třeba podle formuláře, pro který byla vytvořena nebo podle IP. Pokud by se ale využilo i automatické expirace položek, bylo by nutné opět používat zvláštní GC pro obrázky. (To je možným důvodem, proč obrázek ukládat společně s kódem v keši a generovat ho skriptem. Znamenalo by to při použití captchy automaticky přidat routu, která by pak požadavek na obrázek nasměrovala na presenter, který by ho vypsal. Celkem overkill. Jiným řešením by bylo vytvořit Nette\Extras\Captcha\CaptchaStorage a GC přepsat, aby mazal i obrázky.)

Pro detekci robota bych asi použil další třídu. Pak by mohlo existovat i rozšíření Captcha, která by s ní spolupracovala. Daly by se tam registrovat různé akce a stanovit pro ně kritéria. Údaje by se automaticky logovaly a třída by potom uměla říct, zda je daná akce povolená. Dá zneužít skriptu na generování captchy a zaplnit disk obrázky. Podobně jde ale zneužít i sessions, proto by řešení mělo být na obecnější úrovni.

Možná už je jasnější, proč se mi do toho nechtělo. Třeba něco zkusím udělat, ale asi to nebude hned. Dnes může být obtížné vygenerovat obrázek, který nebude strojově čitelný, což mě trochu odrazuje s tím vůbec začínat. Trochu to nahrává použití reCaptcha.

1. Fajn, tak já si to dám za úkol. Uvítal bych připomínky k mému rozboru, abych se měl čeho držet.
2. Myslím, že by to chtělo řešit ještě obecněji než na úrovni AppForm, ale v důsledku by mohla existovat podpora i pro něj. Tento problém se zatím nebudu pokoušet řešit, můžeme ale prodiskutovat, jak by ochrana měla vypadat.

Nejak mi unika proc chcete obrazek kesovat?

1. vygeneruji text pro captcha
2. ulozim jej do session
3. vytovrim stranku
4. nejaky php script vygeneruje obrazek dle dat v session
5. porovnam opsani se session, a session vyprazdnim

Mozna jeste to cele zajistit nejakym tokenem aby slo pracovat ve vice oknech.

Nejak mi unika proc chcete obrazek kesovat?

Ty obrázek ukládáš do session, já do keše. Chtěl jsem session také uvést jako alternativu, ale zapomněl jsem. Respektive jsem ji jako alternativu chtěl zavrhnout. Uživatel může mít v panelech více formulářů s různou captchou, takže je obrázek stejně nutné označovat nějakým $id, které se pomocí skrytého pole pošle společně s formulářem.

Nemyslel on to phx trošičku jinak? Proč budeš kešovat obrázek, který se bude požadovat nanejvýš jednou? Při každém obnovení stránky se přeci pro captchu generuje nový text. Nemusíš kešovat zhola nic, jako atribut src u tagu img uvedeš nějaký skript, který se při každém požadavku podívá do session a na základě textu v ní uloženém vygeneruje obrázek a pošle ho prohlížeči.

Osobne mi prijde ukladat obrazek na disk zbytecne. Jen bych do SESSION ukladal onen text na opsani a dle nej generoval obrazek. Ano pokazde bude kapku jinaci, ale text bude stejny. Zalezi jen kdy a jak zmenis obsah v SESSION:)

Kód je tady.