Zpět na seznam článků     Zpět na článek

Komentáře ke článku

 
 
 BBCode
Sandokan | 2a00:1028:96c6:834a:59b1:6e50:b36f:*14.8.2014 9:59
Zajímavý článek, porovnávání MySQL mě opravdu překvapilo. Otestoval jsem tento problém s MySQLi za pomocí "prepared statement" a ani připravené dotazy vás neochrání.

A dále přidávám další z tisíce způsobů jak se ochránit:
V rámci optimalizace databáze je vhodné přidávat klauzuli "LIMIT 1" v místech, kde víte že dotaz vrátí právě jeden (nebo žádný) řádek. Pokud pak při ověření hesla z databáze vytáhnete 1 řádek, stačí si z něj načíst primární klíč (ID) a právě ten používat k načítání všech dalších informací (oprávnění).

Další ochrana je, pokud používáte na hesla osolené hashování. Pak potřebujete z databáze vytáhnout (zahashované) heslo pro konkrétního uživatele (opět trik s ID) a už vám jednoduše nepostačí dotaz typu "SELECT * FROM users WHERE login='$login' AND password='$password'". Tedy nelze najít v databázi všechny řádky pro které by heslo náhodou sedělo, protože ověření může provést pouze PHP skript.
.cCuMiNn. | E-mail | Website | PGP26.6.2014 17:34
rold: Toto řešení je v článku uvedeno: Obrana před útoky SQL Truncation spočívá například v osekání řetězců obdržených od uživatelů a teprve následných kontrol.
BTW: Nejde o to osekat mezery a bílé znaky, řetězec se musí oříznout celý, ať už obsahuje cokoliv. Například funkce TRIM v tomto případě tedy nezabere.

----------
Teprve když vstáváte s hackingem a uléháte s myšlenkou na něj, máte šanci být hackerem.
rold | 94.242.66.*26.6.2014 15:39
Proč to neřešit přímo před odeslaním SQL požadavku, stačí jen osekat mezery a speciální znaky, a nikdy se tohle stát nemůže.
.cCuMiNn. | E-mail | Website | PGP30.5.2014 7:52
nekdo: Toto je naprosto nedostatečné řešení, protože se dá obejít na straně klienta. I když máš nastaveno maxlength na inputu, nic ti nebrání odeslat požadavek s delším textem. Maxlength slouží jen pro oznámení, že delší texty nejsou přípustné, ale ošetření musí být implementováno vždy na straně serveru.

----------
Teprve když vstáváte s hackingem a uléháte s myšlenkou na něj, máte šanci být hackerem.
nekdo | 217.30.64.*30.5.2014 0:41
co treba nastavit maxlength na input? :D kdo tuhle blbost vymyslel... :D
Lennie | 80.250.18.*21.5.2014 14:09
A bude to platit samozřejmě jen u sloupce typu char :), čili s pevnou délkou řetězce. U varcharu ne, tam mezery na konci zůstávají.
Lennie | 94.113.2.*21.5.2014 10:44
Čekal bych že unique index bude jasné nastavení. To se vážne v aplikaci budu spoléhat vždy na explicitní kontrolu?

Nenastavit tenhle sloupec jako unique by dávalo smysl jen v případě že by bylo potřeba uchovávat historii, nemazat záznamy a jen nastavovat nějaký is_valid flag.
.cCuMiNn. | E-mail | Website | PGP20.5.2014 23:36
duri, ProbablyYes: Vaše elegantní řešení byla doplněna do článku, díky.

----------
Teprve když vstáváte s hackingem a uléháte s myšlenkou na něj, máte šanci být hackerem.
ProbablyYes | 90.177.39.*20.5.2014 20:18
Nebylo by možné pole autor ošetřit už v mysql označením pole jako unique? Pokud si databáze myslí, že "admin" a "admin ", je to samé, takové ošetření by mělo být dostačující - nebo se mýlím?
Heh | 85.160.9.*20.5.2014 10:40
Dost zajimave jak mysql vyhodnocuje podminky. ;-) To je nejaky bug ne? Hih

Stránky: 1 2