Query Injection je typ útoku, při kterém útočník zneužívá nezabezpečené vstupy aplikace k vložení škodlivých dotazů na databázi. Místo aby aplikace přijala jen legitimní parametry od uživatele, útočník dokáže do dotazu „vstříknout“ vlastní příkazy, které mohou vést k neoprávněnému čtení, změně nebo dokonce smazání citlivých dat.
Jak to funguje
Představme si jednoduchý scénář: webová stránka umožňuje vyhledávání uživatelů zadáním jména do textového pole. V ideálním případě aplikace vezme zadaný řetězec, vloží ho do SQL dotazu a vrátí odpovídající záznamy. Pokud ale nedojde k validaci či úniku speciálních znaků, stačí útočníkovi přidat k běžnému jménu kus SQL příkazu, například:
‘; DROP TABLE users; --
A tím nechtěně rozbije původní dotaz a spustí vlastní příkazy, které mohou zničit celou tabulku uživatelů.
Varianty útoků
V praxi existuje hned několik podob query injection. Nejznámější je SQL Injection, kdy se zneužívají dotazy v jazyce SQL. V prostředích NoSQL mohou útočníci podobně zasahovat do dotazů MongoDB, Elasticsearch nebo jiných databází. V REST API může dojít k “Injection” i v případech, kdy se do URL parametrů nebo těla JSONu dostanou škodlivé fragmenty.
Skutečné případy z historie
Mezi největší incidenty spojené se SQL Injection patří útok na americkou firmu Heartland Payment Systems (2008), při kterém hackeři ukradli miliony kreditních karet. Příčinou byla právě díra v ověřování vstupů na webových formulářích. V roce 2014 zase útočníci zneužili NoSQL Injection k úniku dat z MongoDB serverů několika startupů, které nechaly otevřenou administrátorskou konzoli.
Důsledky útoků
Zranitelnost typu query injection může vést k masivnímu úniku osobních i finančních údajů, poškození reputace, právním sporům a velkým finančním pokutám (například v rámci GDPR). Pokud útočník získá přístup k administrátorským datům, může manipulovat se záznamy, vynést citlivé právní dokumenty nebo zpřístupnit firemní interní systémy.
Jak se bránit
Nejúčinnější ochranou je parametrizace dotazů, kdy se vstup od uživatele nikdy nepřipojuje přímo do textu dotazu, ale předává jako parametr, který databáze interně ošetří. Dále je dobré používat ORM (Object‑Relational Mapping) knihovny, mít minimální práva pro přístup k databázi, pravidelně auditovat kód a automatizovaně testovat aplikaci na řadu injection scénářů. Zásadní roli hraje i web application firewall (WAF), který dokáže zachytit neobvyklé vzory v příchozích požadavcích.
Závěr
Query Injection ukazuje, jak kritické je důkladné ošetření uživatelských vstupů a správné nastavení komunikace s databází. Tato hrozba patří k těm nejnebezpečnějším, protože útočníkovi stačí jeden zle ošetřený formulář, aby získal přístup k záznamům celé organizace. Investice do parametrizace, automatizovaných testů a bezpečnostních zařízení se proto vyplatí mnohonásobně.
