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

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.

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.

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.

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.

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

Pokud vim tak nejen v americke

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

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.

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

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

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.

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.

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.

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

.. 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é"... :))

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.

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

Tak, a ted se autor muze citit, jako drsny igigi! Ukazal, ze i ON dokaze neco tak velkeho a ze igigi neni zadny borec! (/ironie)

Zatleskejme autorovi clanku a podporme tak jeho ego!
Je to borec, ze jde v igigiho slepejich.. Vse nazorne ukazal i pro blbecky (takze ted kazde pako bude dropovat databaze.. skvele) a zverejnil strukturu tabulky - jako igigi, proste WOW!

Seriously, get a life!