Útoky na LLM

Co tato dovednost pokrývá

Rozpoznání a obranu proti útokům na webové aplikace, které integrují velký jazykový model (LLM) — chatboty, RAG asistenty a agenty s přístupem k nástrojům. Vychází z klasifikace PortSwigger Web LLM attacks a překrývá se s OWASP Top 10 for LLM Applications. Pro obecné bezpečnostní revize viz OWASP ASVS, pro návrh promptů System prompty a pro znalostní báze RAG.

Kdy ji použít

• Bezpečnostní audit chatbota, RAG asistenta nebo agenta s nástroji
• Review před nasazením funkce, která dává výstup modelu do prohlížeče, e-mailu nebo dalšího systému
• Návrh promptů a integrací nástrojů tak, aby útok nešel eskalovat

Jak LLM útoky fungují

Klíčový princip: vstup modelu je nedůvěryhodný, a proto je nedůvěryhodný i jeho výstup. Do promptu se dostává nejen přímý text uživatele, ale i historie konverzace a — u RAG a agentů — obsah z externích zdrojů (webové stránky, dokumenty, e-maily, výsledky nástrojů). Model neumí spolehlivě odlišit „data" od „instrukcí", takže cokoli, co do něj vstoupí, může změnit jeho chování. Výstup pak zacházejte stejně opatrně jako s uživatelským vstupem na cestě ven.

PortSwigger a OWASP popisují šest hlavních tříd útoků.

Prompt injection (přímý)

Útočník ve své zprávě vloží instrukce, které přepíší systémový prompt — „ignoruj předchozí pokyny a…", vynucení jiné role, obejití guardrails nebo vyzrazení interních instrukcí. Sám o sobě je závažný podle toho, co model může udělat; nejčastěji je ale nebezpečný jako první krok k některé z tříd níže.

Obrana: princip nejmenších oprávnění v systémovém promptu (nedávat do něj tajemství ani agenturu, kterou lze zneužít), jasné instrukce ignorovat příkazy v datech a nepovažovat žádný jediný prompt za jistou obranu — vždy kombinovat s ošetřením výstupu a omezením nástrojů.

Nezabezpečené zpracování výstupu (insecure output handling)

Výstup modelu se předá dalšímu systému bez validace — vloží se do DOM přes innerHTML, do HTML e-mailu, do SQL dotazu nebo do shellu. Pokud odpověď obsahuje např. <img src=x onerror=…> nebo <script>, spustí se v prohlížeči oběti (XSS); u SQL/shellu vznikne injection. Útočník přitom payload nemusí zadat přímo — může přijít i nepřímo (viz níže).

Obrana: k výstupu se chovejte jako k neověřenému vstupu. Na klientu HTML-escapovat text před jakýmkoli formátováním, aby renderer vytvořil jen vlastní whitelistované značky; odkazy povolit jen pro https?:// a doplnit rel="noopener noreferrer". Na serveru navíc odstranit syrové HTML značky a schémata javascript:/data:/vbscript:. Parametrizovat SQL a nikdy nesestavovat shellové příkazy z výstupu modelu.

Nadměrná agentura (excessive agency)

Model má přístup k API či nástrojům, které umí měnit stav — poslat e-mail, zapsat do databáze, utratit peníze, smazat data, stáhnout soubor. Přes prompt injection ho lze přimět tyto nástroje zneužít nad rámec zamýšleného účelu.

Obrana: dávat modelu jen nejnutnější nástroje. Cíle akcí (příjemce e-mailu, cesta, URL) brát z pevné konfigurace nebo whitelistu, ne z volného textu uživatele či modelu. Nástroje pro čtení oddělit od zápisových; destruktivní operace nechat schválit člověkem, ne na uvážení modelu.

Nepřímý prompt injection (indirect)

Instrukce se do modelu nedostane přímo v chatu, ale schovaná v obsahu, který model zpracovává — scrapovaná webová stránka, e-mail, komentář, dokument v RAG znalostní bázi. Když je pak tento text zařazen do promptu, model může skryté příkazy vykonat — třeba vypsat XSS payload jiným uživatelům nebo vyzradit data. Je zákeřný tím, že oběť ani nemusí být ten, kdo obsah vložil.

Obrana: nedůvěryhodný obsah v promptu jasně ohraničit (delimiter) a označit jako „pouze data, nikdy instrukce"; do systémového promptu přidat pokyn ignorovat příkazy uvnitř znalostní báze. Kombinovat s ošetřením výstupu — kdyby injekce prošla, XSS payload se neutralizuje až na výstupu.

Otrávení trénovacích dat (training data poisoning)

Data, na kterých je model trénovaný nebo doladěný — případně obsah indexovaný do znalostní báze — jsou kompromitovaná, takže model vrací nepravdivé či zavádějící informace, nebo obsahuje skrytá zadní vrátka. Vzniká z nedůvěryhodných či příliš širokých datových zdrojů.

Obrana: kurátorovat trénovací i indexovaná data z ověřených zdrojů. U RAG aplikací, které lokálně netrénují, se riziko redukuje na „znalostní báze je nedůvěryhodná" — řešte ji jako nepřímý prompt injection.

Únik citlivých trénovacích dat (leaking sensitive training data)

Útočník cílenými dotazy vytáhne důvěrné informace, které se model „naučil" nebo které má v kontextu — dokončováním frází, dotazy typu „připomeň mi…" nebo obcházením filtrů. Týká se i tajemství vložených do systémového promptu.

Obrana: tajemství (klíče, interní URL, osobní údaje) nikdy nedávat do promptu ani do znalostní báze — co tam není, nejde vytáhnout. Omezovat, jaká data se do kontextu vůbec dostanou, a filtrovat výstup na citlivé vzory.

Doporučené postupy

• Vstup i výstup jsou nedůvěryhodné. Escapujte a sanitizujte výstup modelu na každém sinku (DOM, e-mail, SQL, shell).
• Nejmenší oprávnění. Model dostane jen nezbytné nástroje; citlivé cíle z konfigurace, ne z textu.
• Oddělte data od instrukcí. Ohraničte nedůvěryhodný obsah v promptu a instruujte model ignorovat příkazy v datech.
• Obrana do hloubky. Systémový prompt sám o sobě není bezpečnostní hranice — kombinujte prompt, ošetření výstupu a omezení nástrojů.
• Žádná tajemství v promptu ani znalostní bázi.
• Testujte útoky. Ověřte payloady (<img onerror>, <script>, javascript: odkaz), zkuste nepřímou injekci přes zaindexovanou stránku a pokus o zneužití nástrojů.

Zdroj klasifikace: PortSwigger — Web LLM attacks.