A05:2025 Injekce (Injection)

Pozadí

Injekce (Injection) klesá o dvě pozice z 3. na 5. v pořadí a zachovává relativní pozici vůči A04:2025-Kryptografická selhání (Cryptographic Failures) a A06:2025-Nezabezpečený návrh (Insecure Design). Injekce je jednou z nejvíce testovaných kategorií, přičemž 100 % aplikací je testováno na nějakou formu injekce. Má největší počet CVE ze všech kategorií, přičemž zahrnuje 37 CWE. Injekce zahrnuje Cross-site Scripting (vysoká četnost / nízký dopad) s více než 30 000 CVE a SQL Injection (nízká četnost / vysoký dopad) s více než 14 000 CVE. Masivní počet nahlášených CVE pro CWE-79 Improper Neutralization of Input During Web Page Generation („Cross-site Scripting“) snižuje průměrný vážený dopad této kategorie.

Tabulka skóre

Počet mapovaných CWE	Max míra výskytu	Průměrná míra výskytu	Max pokrytí	Průměrné pokrytí	Průměrná vážená zneužitelnost	Průměrný vážený dopad	Celkový počet výskytů	Celkový počet CVE
37	13,77 %	3,08 %	100,00 %	42,93 %	7,15	4,32	1 404 249	62 445

Popis

Zranitelnost typu injekce je chyba aplikace, která umožňuje odeslat nedůvěryhodný uživatelský vstup do interpretu (např. prohlížeči, databázi nebo příkazové řádce) a způsobuje, že interpret provede části tohoto vstupu jako příkazy.

Aplikace je zranitelná vůči útoku, pokud:

Uživatelem dodaná data nejsou aplikací validována, filtrována ani sanitizována.
Dynamické dotazy nebo volání bez parametrizace a bez kontextově závislého escapování jsou používány přímo v interpretu.
Neočištěná (nesanitizovaná) data jsou použita v parametrech vyhledávání ORM (objektově-relační mapování) k získání dalších citlivých záznamů.
Potenciálně nepřátelská data jsou přímo použita nebo zřetězena. Výsledný SQL dotaz nebo příkaz pak obsahuje jak strukturu, tak i škodlivá data – v dynamických dotazech, příkazech nebo uložených procedurách.

Mezi nejčastější typy injekcí patří SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP a Expression Language (EL) nebo Object Graph Navigation Library (OGNL) injekce. Princip je napříč interpretry stejný. Detekce se nejlépe provádí kombinací kontroly zdrojového kódu a automatizovaného testování (včetně fuzzingu) všech vstupů: parametrů, hlaviček, URL, cookies a datových vstupů ve formátech JSON, SOAP a XML. Zařazení nástrojů SAST, DAST a IAST do CI/CD pipeline může pomoci odhalit injekční zranitelnosti ještě před nasazením do produkce.

V souvislosti s LLM se rozšířila i příbuzná třída injekčních zranitelností. Těm se samostatně věnuje OWASP LLM Top 10, konkrétně LLM01:2025 Prompt Injection.

Jak tomu zabránit

Nejlepší způsob, jak zabránit injekci, vyžaduje oddělit data od příkazů a dotazů:

Preferovanou možností je použití bezpečného API, které se zcela vyhne použití interpretu, poskytuje parametrizované rozhraní nebo umožní migraci na nástroje pro objektově-relační mapování (ORM). Poznámka: I když jsou uložené procedury parametrizované, mohou stále vést k SQL injekci, pokud PL/SQL nebo T-SQL zřetězí dotazy a data nebo vykoná nepřátelská data pomocí EXECUTE IMMEDIATE nebo exec().

Pokud není možné oddělit data od příkazů, můžete hrozby snížit pomocí následujících technik.

Používejte pozitivní validaci vstupů na straně serveru. Nejedná se o úplnou ochranu, protože mnoho aplikací vyžaduje speciální znaky, například v textových polích nebo v API pro mobilní aplikace.
U všech zbývajících dynamických dotazů escapujte speciální znaky pomocí konkrétní escape syntaxe daného interpretu. Poznámka: SQL struktury, jako jsou názvy tabulek, názvy sloupců apod., nelze escapovat, a proto jsou názvy struktur dodané uživatelem nebezpečné. Jde o běžný problém v softwaru pro tvorbu reportů.

Upozornění: Tyto techniky zahrnují parsování a escapování složitých řetězců, což je činí náchylnými k chybám a málo odolnými vůči drobným změnám v základním systému.

Příklady scénářů útoků

Scénář #1: Aplikace používá nedůvěryhodná data při sestavování následujícího zranitelného SQL volání:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Útočník upraví hodnotu parametru id ve svém prohlížeči tak, aby odeslal: ' OR '1'='1. Například:

http://example.com/app/accountView?id=' OR '1'='1

Tím se změní význam dotazu tak, že vrátí všechny záznamy z tabulky accounts. Nebezpečnější útoky by mohly upravit nebo smazat data, nebo dokonce vyvolat uložené procedury.

Scénář #2: Slepá důvěra aplikace frameworkům může vést k dotazům, které jsou stále zranitelné. Například Hibernate Query Language (HQL):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

Útočník zadá: ' OR custID IS NOT NULL OR custID='. Tím obejde filtr a vrátí všechny účty. Přestože HQL obsahuje méně nebezpečných funkcí než „čisté“ SQL, při konkatenaci (zřetězení) uživatelského vstupu do dotazů stále umožňuje neoprávněný přístup k datům.

Scénář #3: Aplikace předává uživatelský vstup přímo do příkazu operačního systému:

String cmd = "nslookup " + request.getParameter("domain");
Runtime.getRuntime().exec(cmd);

Útočník zadá příkaz example.com; cat /etc/passwd, aby provedl libovolné příkazy na serveru.