Podstata útoku

Jak už název techniky napovídá, podstatou SQL injection je vložení kódu do SQL databáze, přičemž tento úkon zneužívá zranitelnosti v databázové nebo aplikační vrstvě (podvržení dotazu). Přitom právě SQL databáze jsou jádrem mnoha aplikací. A ve spojení se skriptovacími jazyky tvoří jádro mnoha webů.
Chyba se projevuje v okamžiku, pokud uživatelský datový vstup do SQL (Structured Query Language) není dostatečně filtrován na přítomnost speciálních znaků nebo uživatelský vstup není správně vložen – a je následně vykonán. Dodáváme, že SQL injection je známý i jako SQL insertion attack – útok na SQL vložením (kódu).
Pokud bychom chtěli být obecnější, můžeme také říci, že k této situaci (a nemusí jít o typ útoku) dochází, když je jeden programovací jazyk vložený do druhého. Pro tento útok je zneužitých mnoho rozšířených technologií, namátkou jmenujme ASP, ASP.NET, PHP, JSP, CGI a další.
Nebude na škodu, pokud už nyní zdůrazníme pointu celého problému: jedná se o relativně jednoduchý typ útoku, kterému se dá vyhnout striktním dodržováním zásad bezpečného kódování. Stačí escapovat potenciálně nebezpečné znaky, které v uživatelském vstupu nemají co dělat. Nejde tedy o něco záhadného a složitého. Nebo o hrozbu, nad kterou bychom nemohli mít kontrolu.

Směry útoku

Připomínáme také, že v případě úspěšného zneužití útoku SQL injection často nejde o bezpečnostní chybu v pravém slova smyslu, ale o to, jakým způsobem je napsaný kód aplikace. Potenciálně zranitelná je každá stránka, která může zpracovávat SQL příkazy. Útočník přitom vůbec nemusí mít možnost editovat celý SQL dotaz (což beztak není možné téměř nikdy), stačí editovat jen určitou část (hodnotu parametru apod.).
Útok přitom může být vedený z několika různých směrů. Asi nejjednodušeji představitelné je napadení skrze webový formulář, do kterého mohou uživatelé vkládat data – pokud tato nejsou následně při zapisování do databáze dostatečně ošetřovaná. Druhým možným vektorem vedení útoku je manipulace s URL odkazy: i s jejich pomocí totiž lze (za určitých okolností) měnit záznamy v SQL. A do třetice: modifikovat SQL lze i pomocí záměrně upravených cookies.
Z tohoto výčtu plyne i jedno neradostné zjištění: všechno, co útočník potřebuje k tomu, aby mohl provést útok SQL injection, je vlastně jen webový prohlížeč. Pak je ještě zapotřebí trocha štěstí či trpělivosti (záleží na tom, jak to nazveme) při hledání názvů tabulek a položek v databázi. Proto je tento typ útoku tak rozšířený. Oblibě napomáhá i naprostá nezávislost útoku na programovacím jazyku, ve kterém je aplikace využívající SQL databázi napsána. Útok SQL injection se navíc netýká jen některých platforem, ale jeho provedení je možné na všech databázích SQL bez rozdílu.
Pro úplnost dodáváme, že existují dvě základní varianty SQL útoků. Jedna je označována jako „first order“ a dochází při ní k přímému vložení kódu do SQL databáze (některou z výše zmíněných metod). Potom je to útok „second order“, kdy dochází k vložení škodlivého kódu do jiných dat (třeba do tabulky) – a až s nimi coby s nositelem do SQL databáze.
Speciálním případem je „blind SQL injection“, kdy sice dochází k úspěšnému útoku, ale agresor jeho výsledky nevidí a nemá možnost si je ihned ověřit. Záleží totiž na logice zpracování příkazů v dotyčné databázi, zdali je výsledek útoku vidět okamžitě, či nikoliv.

Praktické zneužití SQL

Typickým důsledkem úspěšného SQL injection útoku je získání rozličných hesel z databáze nebo obcházení přihlašovacích formulářů (tedy neoprávněný přístup). Jedná se ale o typické příklady, nikoliv všechny: možnosti této techniky útoku jsou nepoměrně širší. Agresoři takto s oblibou modifikují ceny v internetových obchodech (či jakékoliv záznamy v databázi) nebo vytvářejí červa schopného následně se aktivovat (na počítači patřícímu uživateli, který si nechal zobrazit výsledku SQL dotazu).
Zdali útočník získá přístup k vlastní databázi, závisí na úrovni bezpečnosti celého systému. Jsou databáze, které mají nastaveno jen přijímání příkazů určitého typu, kdy je role útočníka ztížena. Ovšem pokud se mu nepodaří modifikovat systém nebo záznamy, stále ještě zbývá možnost, že se mu podaří číst citlivé informace.
Speciální způsob zneužití nabízí MSSQLServer, který umožňuje zřetězení příkazů databáze, což společně s vloženými procedurami přináší útočníkovi možnost, jak ovládnout celý systém (nikoliv pouze databáze). Skutečné důsledky jsou pak odvislé od aktuálních práv SQL serveru: pokud běží pod účtem systémového administrátora nebo jiným účtem s administrátorskými právy, může si útočník vytvořit nového uživatele s administrátorskými právy... Pokračovat snad není nutné.
Dnes už nejsou SQL injection útoky prováděny jen cíleně na vybrané servery, ale také masově. Jako první tak učinil botnet Asprox, jehož tvůrci nasadili na „své“ počítače nástroj určený k SQL injection útokům. Tento nástroj přitom používal Google k vyhledávání serverů vhodných pro napadení: do nich pak právě pomocí SQL injection vkládal kód, který zajišťovat přesměrování návštěvníků webu na stránky obsahující škodlivý kód. Pokud se i tento úspěšně instaloval na počítač, kruh se uzavřel a nově infikovaný stroj se stal součástí sítě Asprox. Jen za první den útoku se podařilo tomuto automatickému nástroji napadnout přes jeden tisíc serverů...

Boj proti SQL injection

Základem úspěšné ochrany před SQL injection je maximálně zmenšit plochu, která může být vystavena vlivu útočníka. Tedy přidělit jen minimální privilegia a nastavit velmi striktní (a vynutitelná) pravidla. Sem patří třeba nepoužívání základního účtu systémového administrátora.
Často se v literatuře nebo na webových fórech můžeme dozvědět spoustu rad a tipů, jak problematiku nebezpečných parametrů vyřešit. Je pravdou, že většina z nich pomáhá zvýšit úroveň ochrany (odesílání formuláře metodou POST, která brání vložení škodlivých dat do URL, vypnutí vypisování chyb apod.), ale stejně tak je pravda, že neřeší jádro problému a útočníka nezastaví. Jedním z takovýchto nesmyslných doporučení je nahrazování apostrofu uvozovkami – což funguje jen do chvíle, než útočník použije dotaz v hexadecimální podobě. Při zřetězení se ovšem z hexadecimálního tvaru stává kód i s apostrofy...
Hlavním problémem zůstává právě používání zřetězení stringů do výsledného dotazu a následné odeslání této dávky na server. Kdysi neměli programátoři k dispozici jinou volbu, takže museli spoléhat na různé kontroly a filtry. Leč drtivá většina těchto ochran byla postupně prolomena a obejita – jen mnozí programátoři si toho nevšimli. Za řešení odpovídající úrovni dnešní doby se považuje oddělené předávání dotazu a jeho parametrů databázovému serveru.
S obranou je přitom zapotřebí počítat jak na straně aplikace (kontrola a úprava vstupních dat), tak na straně databáze (uživatelská práva – stačí povolit jen základní SQL příkazy).