přesně .. s referrerem mám špatný zkušenosti .. jednak weby v phpku dělám většinou tak, že se stránka volá přes parametr a ne souborem, přičemž index pak includuje jednotlivý soubory ... a abych zamezil vlání souborů, tak se na indexu nadefinuje session, která se před "exit"em zabije. Na každé stránce se pak kontroluje jestli má ta session správnou hodnotu a pokud ne, tak se includuje file, kterej nastaví redirect na index. Což mě nyní inspirovalo k tomu,ž e by se ta ochrana dala napsat tak, že klasickej form, druhá stránka, která nabídne data ke zkontrolování, přičemž data z toho formuláře hashne a uloží do session. No ... a před přidáním do db se ten opětovnej hash s tou session hodnotou musí rovnat. Tím též ošetříme stav, kdy se boti naučí session používat ... pokud nebudou znát hashovací algoritmus, tak budou v prdeli tak jak tak ... Pro začátek by myslím ten algoritmus mohl spočítat délku všech vstupů, složitější by sčítal ascii jednotlivých znaků, další stupně si zajisté domyslí každý sám ... T.V. Jiri Matejka napsal(a): >>Tak kontrola HTTP_REFERER nepomohla :-( >>Nezbude asi než tam dát ještě jedno políčko, případně fakt ten obrázek :-(( >> >> > >udelal jsem si takovou jednoduchou kontrolu v PHP ve spolupraci s >session - kazda formularova stranka ma specificky session kod ktery je vazan >se session co maji prochazejici uzivatele >vetsina spambotu pokud uz zna danou formularovou stranku pak uz posila >jen POST data primo bez navstevy stranky formulare - tudiz neni brana jako >prochazejici navstevnik a data jsou zahozena >uspesnost 95% oproti tomu co se mi tam sypalo pred tim > >pro vetsi uspesnost je doporuceno to kombinovat s vyhledavanim >klicovych slov a spojeni > >DFly > > > >Received on Wed, 26 Oct 2005 19:04:59 +0200
This archive was generated by hypermail 2.1.8 : 26. 10. 2005, 19:04 CEST