Komentáře ke článku

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. |

26.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. |

30.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. |

20.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

Komentáře ke článku

Hacking keywords