Weblabor

Okés, valami ilyesmit sejtettem, tehát csak akkor működik a dolog, ha a keresett cucc kétszer szerepel benne. Ez végülis kivédhetetlen, mert tetszőleges input-ba beírhatod a tokent tesztnek... Egyedül a js kliens + REST api véd ellene, mert ott csak egy 404 headert kapsz vissza, az űrlapba írt dolgokat a kliens tárolja a böngészőben. Meg esetleg ha random hosszúságú stringet fűzöl az űrlapodhoz minden esetben, de ott is ügyesen kell megválasztani a határokat, hogy a tömörítés megérje, de mellette annyi változatot kelljen végigpróbálni, hogy pármilliárd évig tartson a törés. Még amit lehet, hogy loggolni a munkamenetben, hogy hány egymás utáni sikertelen próbálkozás volt, és bizonyos számú után kiléptetni.

Én szerintem a legkézenfekvőbb, ha a http szerver minden kérésre automatikusan ráheggeszt egy random hosszúságú headert. Így a tartalom ugyanúgy kesselhető marad. A szükséges hossz tartományt meg ki lehet számolni. Gondolom ott az számít, hogy x db próbálkozásból bájt pontossággal meg lehet e mondani a várható értéket vagy sem. Ha viszont erre kényszerítjük a hackert, akkor már egy fokkal könnyebb dolgunk van, mert az ilyen ismétlődő hibás kérések még könnyebben loggolhatóak, mondjuk ha minden hibás kérésre csinálunk egy hasht egy gyors algoritmussal, és az adott hash sokszor ismétlődik egymás után, akkor ki lehet léptetni az illetőt a munkamenetből, illetve figyelmeztetni, hogy valszeg támadó oldalt néz. Ehhez elég csak a hibakezelő részébe a kódnak betenni, hogy csináljon hasht a hibás kérésekből, tehát a valid kéréseknél ez nem lassítaná az oldalt, csak a hibásaknál... Mondjuk ezt meg ki lehet játszani, ha a hacker betesz egy random string-et a kérésébe, hogy a hash ne ismétlődjön. Bonyolult ez a téma... :D

+1, én is próbálom szoktatni a felhasználókat a 10+ karakteres jelszavakhoz. Nem olyan nehéz ilyet összehozni, mások is csinálták már, pl: "Szezám tárulj!" is 15 karakteres...