SQL injection (vkládání SQL kódu)

Příklady z praxe

1. 01

   Obejití přihlašovacího formuláře

   Přihlašovací stránka skládá dotaz z e-mailu a hesla přímo do textu. Útočník zadá do pole e-mail hodnotu s apostrofem a podmínkou, která je vždy pravdivá, a doplní komentář, jímž odřízne kontrolu hesla. Databáze vrátí první řádek tabulky uživatelů, což bývá administrátor, a aplikace ho přihlásí.

   -- vstup: admin@firma.cz' --
   SELECT id FROM users
   WHERE email = 'admin@firma.cz' --' AND password_hash = '...'

2. 02

   Řazení výpisu podle parametru z URL

   Výpis objednávek předává název sloupce z query stringu přímo do klauzule ORDER BY, protože parametr sem doplnit nelze. Útočník tam vloží poddotaz a čte data z jiné tabulky. Oprava je mapa povolených hodnot: co není v seznamu, spadne na výchozí sloupec.

   const sortable = { date: 'created_at', price: 'total' };
   const col = sortable[req.query.sort] ?? 'created_at';
   db.query(`SELECT * FROM orders ORDER BY ${col} DESC`);

Časté omyly

MýtusPoužíváme ORM, takže SQL injection nás netrápí.

Ve skutečnostiORM chrání jen dotazy, které samo skládá. Jakmile vývojář použije raw SQL, vlastní fragment ve WHERE nebo dynamický název sloupce, je zranitelnost zpátky. Riziko také zůstává v uložených procedurách, které si dotaz sestavují uvnitř databáze.

MýtusStačí odstranit apostrofy a slova jako DROP nebo UNION.

Ve skutečnostiBlacklisty se obcházejí kódováním, komentáři uprostřed klíčového slova nebo změnou velikosti písmen. V číselném kontextu navíc útočník apostrof vůbec nepotřebuje. Spolehlivé je jen oddělení dat od kódu parametrizovaným dotazem.

MýtusAplikace je za HTTPS a přihlášením, tak se k dotazům nikdo nedostane.

Ve skutečnostiHTTPS chrání přenos, ne zpracování vstupu na serveru. Útočník bývá běžný registrovaný uživatel a injection provede přes normální formulář. Velká část případů se navíc týká funkcí dostupných až po přihlášení.

Časté dotazy

Jak poznám v kódu místo náchylné na SQL injection?

Náchylné místo pozná vývojář podle toho, že se text dotazu vzniká spojováním řetězců, formátováním nebo šablonovým literálem, do kterého vstupuje proměnná. Podezřelé jsou také volání typu raw, execute s jediným argumentem nebo dynamicky sestavené klauzule WHERE a ORDER BY. Pomůže grep po znacích plus a interpolaci v okolí slov SELECT, INSERT a UPDATE, statický analyzátor s pravidly pro injection a kontrola uložených procedur, které si dotaz skládají uvnitř databáze.

Chrání parametrizované dotazy proti všem typům SQL injection?

Parametrizované dotazy odstraní injection všude, kde jde o hodnotu: řetězec, číslo, datum. Nepokryjí ale místa, kam parametr syntakticky nepatří, tedy názvy tabulek a sloupců, směr řazení, LIMIT v některých ovladačích a celé fragmenty SQL. Pro ta místa je potřeba whitelist povolených hodnot nebo mapování z klíče na pevný název. Riziko zůstává i tehdy, když se parametr sice předá, ale uvnitř uložené procedury se z něj poskládá další dynamický dotaz.

Co dělat, když už k útoku přes SQL injection došlo?

Po zjištěném útoku je prvním krokem zajistit logy databáze i webového serveru a neupravovat je, protože jsou hlavním důkazem rozsahu. Následuje uzavření zranitelného místa, rotace přihlašovacích údajů k databázi a všech tajemství, která mohla uniknout, a vynucení změny hesel uživatelů. Rozsah úniku se určí z logů dotazů. Pokud unikly osobní údaje, vzniká podle GDPR povinnost posoudit ohlášení dozorovému úřadu zpravidla do 72 hodin a případně informovat dotčené osoby.

Je NoSQL databáze proti injection imunní?

NoSQL databáze imunní není, jen má jinou podobu útoku. Místo SQL syntaxe útočník podstrčí objekt nebo operátor, který změní význam dotazu, typicky operátory porovnání v dokumentových databázích nebo vložený kód do serverem vyhodnocovaného výrazu. Příčina je stejná jako u SQL: nedůvěryhodný vstup se stane součástí struktury dotazu. Obrana spočívá ve validaci typů, odmítnutí vstupů začínajících znakem dolaru a v používání ovladačů, které hodnoty předávají odděleně.

Zdroje

1. SQL Injection Prevention Cheat Sheet(otevře se v novém okně)OWASP Foundation
2. OWASP Top Ten(otevře se v novém okně)OWASP Foundation
3. PREPARE(otevře se v novém okně)PostgreSQL Global Development Group
4. sqlite3: DB-API 2.0 interface for SQLite databases(otevře se v novém okně)Python Software Foundation

Související pojmy

• SQLSQL je deklarativní jazyk pro práci s relačními databázemi, ve kterém se popisuje, jaká data chce uživatel vybrat, změnit nebo definovat, nikoli přesný postup jejich získání. Používá se pro dotazy, vkládání, aktualizace, mazání, tvorbu tabulek, oprávnění i transakční zpracování v mnoha databázových systémech.
• ZranitelnostZranitelnost je slabé místo v softwaru, hardwaru, konfiguraci nebo procesu, které může útočník zneužít k porušení důvěrnosti, integrity nebo dostupnosti systému. Sama o sobě ještě není útokem: riziko vzniká až kombinací zranitelnosti, dostupné cesty ke zneužití, hodnoty ohrožených dat a pravděpodobnosti, že někdo slabinu využije.
• Stored procedureStored procedure je pojmenovaný blok databázového kódu uložený přímo v systému řízení databáze a spouštěný příkazem z aplikace, jiného SQL nebo plánované úlohy. Typicky uzavírá opakovanou změnu dat, validaci nebo dávkové zpracování, takže logika běží blízko dat a pod jedním transakčním i bezpečnostním modelem.
• Formulářová validaceFormulářová validace je kontrola, zda data zadaná uživatelem do formuláře odpovídají očekávanému formátu, rozsahu a obchodním pravidlům, ještě než je aplikace zpracuje nebo uloží. Probíhá ve dvou vrstvách: v prohlížeči kvůli rychlé zpětné vazbě a na serveru kvůli bezpečnosti a integritě dat, protože klientskou kontrolu lze obejít.
• 3D model3D model je digitální reprezentace objektu nebo prostoru ve třech rozměrech, složená z geometrie, materiálů a často i textur, animací či fyzikálních vlastností. Používá se v hrách, filmech, průmyslovém návrhu, architektuře, e-commerce i simulacích, kde software z modelu počítá zobrazení nebo další data.
• 3-D Secure3-D Secure je protokol, který u online platby kartou ověří, že platí skutečně její držitel, typicky potvrzením v bankovní aplikaci. Při úspěšném ověření se zároveň přenáší odpovědnost za podvodnou transakci z obchodníka na vydavatele karty.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.
• Alfa kanálAlfa kanál je složka obrazových dat, která u pixelu určuje míru neprůhlednosti nebo průhlednosti. Doplňuje barevné kanály, typicky RGB, a umožňuje plynulé okraje, stíny, překryvy, masky i skládání vrstev. Hodnota alfa sama neurčuje barvu, ale říká, jak se barva pixelu promíchá s pozadím.