Vlákno názorů k článku Děravé databáze: věčná láska hackerů od pepak - 11) Používejte pro předávání parametrů databázi prepared statements,...

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.

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.

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.

Programovací jazyky s preprocesorem už vymizely?

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.

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

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 ;-)

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

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.

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

Jak otestujete na spravnost obsah varcharu?

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

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

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

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

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.

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

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/

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

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.

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

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.