Názory k článku
Děravé databáze: věčná láska hackerů

11) Používejte pro předávání parametrů databázi prepared statements, která jsou pro to určená a kromě vyššího výkonu také zamezí drtivé většině SQL injection.

Jenže to by PHP frameworky museli programovat lidé, kteří o databázích něco vědí a nemají nezměrnou touhu stále znovu a znovu vynalézat šišaté kolo.

Nebo to rovnou pište v prostředích, kde při práci s databází patří používání typově bezpečných parametrů ke slušnému vychování - jako jsou např. .NET nebo Java.

A pro zasmání:
http://xkcd.com/327/

to je samozrejme blbost, SQLi lze pouzit i v Jave nebo .NET navic tyhle dve veci maji svejch starosti dost se sebou nepotrebujou ani SQLi ;-)

Nepíši, že SQL injection nemůže postihnout aplikaci napsanou v Javě, nebo .NETu.
Píši, že používání parametrů u SQL příkazů je v těchto prostředích "součást slušného vychování". Tedy, že v těchto přostředích se k eliminaci rizika SQL injekce stačí chovat podle elemetárních tutoriálů. Pochopitelně, když někdo SQL injekci hrozně moc chce, tak mu v tom Java ani .NET bránit nebudou a poskládat SQL dotaz ze stringů ze vstupních polí ho nechají.

Prepared Statement zamezi >>>ve vsech<<< pripadech SQL injection, nikoliv v drtive vetsine.

Nikoliv. Jsou případy, kdy je potřeba použít parametr a přitom nejde použít prepared statement - typicky například
"SELECT * FROM tabulka ORDER BY $uzivatelem_urcene_pole".

kde $uzivatelem_urcene_pole je urcite hodnota z ciselniku, ze jo? ;-)

Třeba. Jakým způsobem je zajištěno ošetření proti SQL injection je celkem nepodstatné pro ten účel, který demonstruji - že existují SQL dotazy, kde potřebuji použít parametr a přitom nelze použít prepared statement.

No, já se Vám právě snažil naznačit, že to není pravda.
I u dymamicky skládaného dotazu lze použít prepared statement.

No, a pak se lidé diví, že SQL injection je tak časté. Měl jsem dodat, SQL je ochranou proti SQL injection na správně použitém SQL příkazu. Dynamický ORDER BY je něco, co bych si nikdy nedovolil napsat, a také to nikomu nedoporučuji.

Pokud chcete bezpečně řešit takový dotaz, pak Vám nezbývá než SQL příkaz namnožit:

if col = ... THEN
SELECT FROM ORDER BY 1;
else
SELECT FROM ORDER BY 2;

atd

Haha, jedno řešení lepší než druhé

Problém je v tom, že dnes dělá programátora každý jouda bez vzdělání.

Rád se poučím o optimálním řešení:

* které bude bezpečné,

* kde se Vám budou chytat indexy,

* které bude čitelné.

Přesně tak. U řešení Pavla Stěhuleho si mohu být jistý, že mi tam nevleze dotaz, který by položil databázový server. To mi určitě stojí za to, že napíšu o pár řádek víc.

Vy ale nepíšete jen o pár řádek víc. Vy kopíruju celý dotaz. Předem vím jak to dopadne. Až ho budete měnit, na jeden z výskytů zcela jistě zapomenete.

Takže prosím běžně nad svými programátorskými znalostmi onanovat na jakpsatweb :)

Od toho je testování. Ať už unit testy nebo regresní testy.

Pokud se vyhnu dynamickému SQL, tak poměrně snadno mohu otestovat syntaktickou správnost všech SQL dotazů, které se vyskytují v aplikaci. Dynamické SQL není testovatelné.

Samozřejmě, že tu proti sobě jdou dvě strategie - úspora kódu X efektivitě a bezpečnosti. Souhlasím, můžete udělat chybu. Na druhou stranu - dynamické SQL Vás před chybami neochrání - testovat musíte tak jako tak - a navíc riskujete děravost aplikace.

Jedna věc je, když píšete lokální z internetu nedostupné aplikace - riziko SQL injektáže není až tak velké. Jen riskujete, že Vám uživatelé vygenerují pomalý dotaz, což patrně přežijete. Psát dobré internetové aplikace ovšem vyžaduje docela dost znalostí - pohybujete se v mnohem rizikovějším prostředí a přetížit SQL server náporem uživatelů je mnohem menší problém - tudíž web s trochou větší návštěvností je mnohem lépe optimalizován než typické vnitropodnikové aplikace.

Pomíjíte, že téměř každá SQL má detailní možnosti nastavení práv, takže každá databáze může mít jednoho db uživatele pro web (pouze prohlížení), jednoho pro administraci (zápis) a dalšího pro databázové příkazy (třeba zrovna ten drop tabulky)

Jenže který hosting by tohle uměl a který programátor by to používal?

To nepomíjím. Pomocí práv lze minimalizovat škody způsobené SQL injektáží - nicméně nastavením práv se rizika SQL injektáže nezbavíte - pokud nepřistoupíte k dost razantní strategii a neobalíte všechny SQL příkazy uloženou procedurou, která běží v security definer modu - čímž byste běžného uživatele odřízl.

Nastavení práv v SQL databázi lze pouze minimalizovat dopady. Ale již jen to, že se Vám pomocí SQL injektáže útočník dostane k uživatelským datům, je problém, a tomu se nastavením práv nevyhnete. Všimněte si - většina problémů způsobených SQL injektáží není o tom, že by někdo pozměnil strukturu, ale o tom, že někdo získal data, která získat neměl.

Pokud jsou dotazy u sebe, jako že v příkladu byly, tak si troufám tvrdit, že se na 90% nepřehlédnu. Zbytek snad odhalí testování. Pokud dovolím sestavit SQL dynamicky, neotestuji pravděpodobně všechny možnosti, které mi od uživatele mohou přijít, což je potenciální díra v aplikaci.

Osobně raději vezmu duplicitu kódu než kód, který do databáze pustí něco neočekávaného.

Netvrdím, že bych kopíroval celý dotaz. Pravděpodobně bych ho rozdělil na několik částí. Zde ale už porušuji čitelnost a trochu i bezpečnost, protože nemohu scannováním zdrojáku otestovat syntaktickou správnost všech dotazů.

Pokud máme v debatě pokračovat dál, rád bych slyšel odpověď na Pavlovu otázku s ohledem na 3 zmíněná kritéria.

Vy ale nepíšete jen o pár řádek víc. Vy kopíruju celý dotaz. Předem vím jak to dopadne. Až ho budete měnit, na jeden z výskytů zcela jistě zapomenete.

To je jenom věc toho, jak to napíšete – a do komentáře se to asi napíše v této formě, protože je to nejsrozumitelnější. jinak se to dá samozřejmě napsat jako šablona, kam doplníte vlastní parametr (tedy ne zadaný uživatelem), nebo to můžete mít jako uloženou proceduru na serveru a té předáte jako parametr jenom hodnotu z výčtového typu. Pořád je to tisíckrát lepší než nechat uživatele psát si vlastní SQL příkazy.

a neni potom jednodussi proste vstupni data otestovat, orezat a pokud neodpovidaji pozadavku tak proste zahodit??
Jak to tak pozoruju tady se vymejsli kolo v dobe kdy je davno auto na silnici.

Jak otestujete na spravnost obsah varcharu?

Format lze testovat pouze i ciselnych, logickych a datumovych typu.

Programovací jazyky s preprocesorem už vymizely?

a takhle porad dokola az do rekneme order by 567 ?? no tak to jste kanon chudak vas sql server

To leda v nějakých hodně zvláštních databázích.

Až na malé výjimky nemá smysl uvažovat o Prepared Statement kvůli výkonu - ve většině případů je výkon stejný nebo může být i horší (zase tak často se SQL příkazy neopakují a optimalizace na dnešních strojích už neznamená takové zdržení). Ten soudobý smysl je v ochraně vůči SQL injection. Podobně se chovají tzv. Parametrized Queries - moderní databáze nabízejí obé - PQ mají výhody PP bez jejich nevýhod. Pokud používáte PQ, tak se musíte hodně snažit - v podstatě to nejde, abyste napsal SQL injection zranitelný dotaz. dalším argumentem pro PQ je čitelnost zápisu.

No minimalne na Oracle maji Prepared Statementy velky vyznam pro vykon.
1. vytvoreni exkucniho planu ma slozitost O(n!) kde n je pocet tabulek v joinu. Proto DB vygeneruje max. 80000 exekucnich planu a z nich zvoli nejlepsi.
2. Vytvoreni exekucniho planu vyzaduje exkluzivni zamek na nekterych sdilenych strukturach. Tim muzete zbytecne brzdit ostatni konexe. Vytvoreni exekucniho planu vyzaduje sdileny zamek jinych strukturach. To muze zbytecne zvysovat mnozstvi zprav mezi nody DB clusteru.
3. SQL prikazy se velice casto opakuji a na normalni DB se pomer mezi hard a soft parse pohybuje okolo 1:1000.

Všechny kombinace se určitě nezkoušejí - viz http://redbook.cs.berkeley.edu/redbook3/lec7.html případně hledejte na googlu "dynamické programování".

Čím složitější SQL příkaz, tím méně by se Vám měl v db vyskytovat. Totéž - pokud se v db objevují opakující se SQL příkazy, tak to povětšinou znamená, že se někde udělala chyba - např. špatně konfigurované Hibernate. Konečně u prepared statement hrozí riziko neoptimálních prováděcích plánů z důvodů optimalizace na slepo.

Kola se znovu-vynalézají dnes a denně :) Má to své důvody..

Uplne staci pouzivat dibi - http://dibiphp.com/cs/

Dekuji za clanek. Tusil jsem, ze to takhle nejak funguje.

Mimochodem, Matlab take ma cosi, cemu rika Web Server (pres html formular zadate parametry vypoctu, odeslete Matlabu, ten neco spocita a vrati HTML s vysledkem nebo i obrazek s grafem) a tam lze vytvorit napadnutelne skripty. Na jedne univerzite se mi tak podarilo si na dany server vzdalene nainstalovat do jejich woken vlastni ftp server, ale to byl opravdu extrem.

.. a já měl 20 let za to, že jak v britské tak i americké angličtině se "q" čte jako [kju:] ...

no asi existuje ještě bohemská angličtina, která kreativně mixuje "indžekšn" s "kvé"... :))

Pokud vim tak nejen v americke

On taky původně to byl SEQUEL.

Proč se rozčilujete? Mnohem důkladnější popis se povaluje všude na netu. Cenzura nic neřeší. Pro ukrajinské, ruské, čínské, pákistánské crackery SQL injektáž rozhodně není novinkou. Pro místní uživatele nebo programátory je potřeba naopak osvěta. Kdyby tyto články vycházely 10x denně, tak jedině dobře.

Kašli na to, tím stejně ničeho nedosáhneš. Neboj se, že bys přišel o svou zábavu - podobné články vychází už aspoň 10 let a stále to funguje :) jelikož lidi se prostě nezmění, ikdyž jim to naservíruješ pod nos :)

Jen nevim co se tu resi injektaz pokud pouzivate addslashes tak nemuzete mit problem...

Ale můžete… addslashes() je právě příklad, kdy se jeden problém vyřeší tak, že se vytvoří jiný, který je minimálně stejně velký. addslashes funguje jedině v případě, že jej použijete na všech potřebných místech a nikde jinde, a na vše právě jednou. Používání addslashes je nouze nejvyšší a je dobré jedině pro případ, kdy opravdu nemůžete použít parametrizované dotazy (přičemž jediný přípustný důvod, proč je nemůžete použít, je, že je vámi používaná knihovna neumí).

Nehlede na to, ze addslashes() trpi problemem ruznych kodovani a samo o sobe tak nemusi byt bezpecne. Kdyz uz escape v PHP, tak mysql_real_escape_string(), pg_real_escape_string() a varianty.

To je ale zpusobeno nevhodnym pouzivanim magic quotes a addslashes kdy si to zdvojite. nebo kdyz to pouzivate jinde nez pri skladani SQL.

OK vyuziti mysqli::escape_string je mozna lepsi ikdyz seznam kodovanych znaku je
NUL (ASCII 0), \n, \r, \, ', ", and Control-Z.
takze nevim jak chcete resit kodovani.

Ale stejne tak funguje prepare exec ze jej musite pouzit vsude. navic pri tvorbe filtru no potes..

Podle mě je tu jediný problém, a to že se nepoužívají parametrizované sql dotazy, např. select * from tabulka where id=:id

Přitom je to i rychlejší, protože dotaz je kompilován jen jednou.

Těch rad od autora je tam spousta, protože si není jistý, jak se bránit. Tak doufám, že si přečte tento příspěvek.

Jinak, existují specializované firmy, které také dokáží otestovat zabezpečení webové aplikace.

404. Jaká to náhoda. :P