OWASP Top 10 LLM-alkalmazásokhoz: a kockázatok röviden

Mit tartalmaz az OWASP Top 10 for LLM Applications listája az adatkiszivárgástól a túlzott önállóságig, és hogyan használható egy felülvizsgálatnál.

Téma
AI
Szerző
ARLITECH szakértői csapat
Megjelent

Az OWASP nevét sok fejlesztő a webalkalmazások tíz leggyakoribb kockázatát összefoglaló listáról ismeri. 2023-ban ugyanez a közösség külön listát állított össze a nagy nyelvi modellekre (LLM) épülő alkalmazásokhoz, és azóta átdolgozta. Ez a cikk a 2025-ös kiadás tíz tételét veszi sorra, és azt mutatja meg, mit jelentenek egy chatbot, egy dokumentumokban kereső asszisztens vagy egy eszközöket hívó AI-ágens esetében.

A tételek többsége az alkalmazás egészére vonatkozik. Arról szólnak, honnan kap bemenetet a modell, milyen adatot lát, mit tehet meg a válaszadáson túl, és hova kerül a kimenete. Ezért a lista annak is használható, aki egy már működő rendszert néz át, és annak is, aki most tervez egyet.

Mi az OWASP Top 10 for LLM Applications

Az OWASP (Open Worldwide Application Security Project) nonprofit alapítvány, amelynek projektjeit önkéntes szakemberek írják, és amelyek szabadon hozzáférhetők. Az LLM-alkalmazásokra vonatkozó lista első, 1.0-s változata 2023 augusztusában jelent meg. A 2025-ös változat 2024 novemberében jelent meg; a projekt ma OWASP GenAI Security Project néven fut. Minden tételhez leírás, jellemző példák, megelőzési javaslatok és támadási forgatókönyvek tartoznak.

KódKockázatRöviden
LLM01Prompt InjectionA bemenetbe rejtett utasítás megváltoztatja a modell viselkedését.
LLM02Sensitive Information DisclosureSzemélyes adat, üzleti titok vagy hozzáférési adat kerül a válaszba.
LLM03Supply ChainKompromittált modell, adatkészlet, adapter vagy függőség.
LLM04Data and Model PoisoningManipulált tanító- vagy finomhangoló adat torzítja a modellt.
LLM05Improper Output HandlingA modell kimenete ellenőrzés nélkül jut tovább más rendszerekbe.
LLM06Excessive AgencyA modell a feladatához képest túl sok eszközt, jogot vagy önállóságot kap.
LLM07System Prompt LeakageA rendszerprompt tartalma kiolvasható, és benne olyan adat van, aminek nem ott a helye.
LLM08Vector and Embedding WeaknessesA keresésre épülő (RAG) rendszerek vektortárának hibái.
LLM09MisinformationMagabiztosan megfogalmazott, de hamis válasz, amire valaki döntést épít.
LLM10Unbounded ConsumptionKorlátlan lekérdezés, amely leterheli a szolgáltatást vagy kimásolja a modellt.

A 2023-as listához képest két tétel új: a rendszerprompt kiszivárgása és a vektortárak gyengeségei. A korábbi szolgáltatásmegtagadási tételből lett a korlátlan erőforrás-használat, a túlzott önállóság pedig az ágensek terjedése miatt bővebb tartalmat kapott.

A lista tudatosító dokumentum. Nem szabvány, nincs hozzá tanúsítás, és nem minden tétel egyformán fontos minden rendszerben: egy belső, csak olvasni tudó összefoglaló eszköznél a túlzott önállóság kevésbé égető, mint egy leveleket küldő ágensnél.

Bemenet és kimenet: utasítás-befecskendezés és nem ellenőrzött kimenet

Az első tétel a prompt-injekció, magyarul utasítás-befecskendezés. A nyelvi modell ugyanabban a szövegfolyamban kapja a fejlesztő utasításait, a felhasználó kérdését és a feldolgozandó dokumentumokat, és nincs megbízható módja annak, hogy ezeket szétválassza. Közvetlen esetben a felhasználó maga írja be a felülíró utasítást. Közvetett esetben az utasítás egy weboldalon, e-mailben vagy feltöltött fájlban vár, és akkor lép működésbe, amikor a modell feldolgozza. Az OWASP a korlátozások kijátszását célzó „jailbreak” technikákat is ide sorolja. Képet vagy hangot is fogadó modelleknél az utasítás egy kép szövegében is elrejthető.

Teljes védelmet a lista sem ígér. A javaslatai a hatás korlátozására épülnek: a modell csak a feladatához szükséges jogokat kapja, a külső forrásból érkező tartalom legyen megjelölve és elkülönítve, a kimenet formátumát ellenőrizni kell, a kockázatos műveleteket pedig ember hagyja jóvá. A témát részletesebben a vállalati AI-bevezetés kockázatairól szóló cikk tárgyalja.

Az ötödik tétel ugyanennek a folyamatnak a másik vége. Ha a modell válasza egy böngészőben jelenik meg, SQL-lekérdezésbe, parancssorba vagy egy másik program bemenetére kerül, akkor a klasszikus webes hibák térnek vissza: cross-site scripting, SQL-injekció, távoli kódfuttatás. Egy jól ismert minta, hogy a modell egy Markdown-képhivatkozást ír a válaszba, amelynek URL-jében a beszélgetésből kinyert adat szerepel. Amikor a felület megjeleníti a képet, a böngésző elküldi az adatot a támadó szerverére.

A modell kimenetét ugyanolyan megbízhatatlan bemenetként kell kezelni, mint amit egy ismeretlen felhasználó gépel be. Ugyanaz jár neki, mint bármely más bemenetnek: a megjelenítés helyéhez illő kódolás, paraméterezett lekérdezés, szigorú formátumellenőrzés és a külső hivatkozások szűrése.

Érzékeny adatok és a rendszerprompt kiszivárgása

Az érzékeny adat több úton kerülhet a válaszba. A modell megjegyezhet részleteket a tanító- vagy finomhangoló adatból. A keresésre épülő asszisztens olyan dokumentumot is beemelhet a válasz kontextusába, amelyhez a kérdező felhasználónak nincs joga. A felhasználók maguk is beírhatnak ügyféladatot vagy jelszót egy kérdésbe, ami aztán a szolgáltató naplóiban marad.

Ami nem kell a feladathoz, az ne kerüljön se a tanítóadatba, se a kontextusba. A dokumentumokhoz való hozzáférést a lekérdezés pillanatában, a felhasználó saját jogosultságával kell ellenőrizni, nem egy közös szolgáltatásfiókkal. Külső szolgáltatónál érdemes elolvasni a feltételeket is, mert ezekből derül ki, hol és mennyi ideig tárolják a beküldött szöveget, és felhasználhatják-e a modell továbbtanításához.

A rendszerprompt az a háttérutasítás, amelyet a fejlesztő ad a modellnek a viselkedéséről. Gyakori hiba, hogy belekerül egy API-kulcs, egy belső adatbázis neve, a jogosultsági szintek leírása, vagy egy olyan szabály, amire a biztonság épül („ne add ki a kedvezményes árlistát”). A rendszerpromptot úgy érdemes megírni, mintha nyilvános lenne, mert ügyes kérdezéssel jó eséllyel kiolvasható. A hozzáférési szabályokat a modellen kívül, az alkalmazás kódjában vagy a háttérrendszerben kell érvényesíteni.

Túlzott önállóság és eszközhozzáférés

Amíg a modell csak szöveget ír, a rossz válasz kára korlátozott. Az AI-ágens viszont eszközöket hív: levelet küld, fájlt olvas, jegyet nyit, adatbázist módosít. Az OWASP három gyökérokot különít el:

  • túl sok funkció: a levelek összefoglalásához kapott bővítmény küldeni és törölni is tud, vagy az ágens általános parancssori hozzáférést kap egy szűk feladathoz;
  • túl sok jog: az olvasáshoz elég lenne a csak olvasási jog, az ágens szolgáltatásfiókja mégis írhat, és a felhasználó saját jogai helyett egy mindent látó fiókkal dolgozik;
  • túl sok önállóság: nagy hatású művelet emberi jóváhagyás nélkül fut le.

Ez a tétel a prompt-injekcióval együtt veszélyes igazán. Eszközök nélkül egy közvetett injekció főleg a válasz tartalmát tudja befolyásolni, legfeljebb a kimenet megjelenítésén keresztül szivárogtat adatot. Ha az ágensnek joga van levelet küldeni, ugyanaz a rejtett utasítás adatot juttathat ki a szervezetből.

A javasolt ellenintézkedések ismerősek a jogosultságkezelésből. Kevés és szűk feladatú eszköz kell egy nyitott parancsfuttató helyett. A háttérrendszer hívásai a felhasználó nevében, korlátozott hatókörű tokennel menjenek. A jogosultságról a célrendszer döntsön, a modell kérése ehhez csak bemenet. A visszafordíthatatlan műveletekhez megerősítés kell, és minden eszközhívás kerüljön naplóba. Az ágensek jogosultsági modelljét részletesen az AI-ágensek eszközhozzáféréséről szóló cikk járja körül.

Gyors próba: soroljuk fel, milyen eszközöket hívhat az ágens, és mindegyik mellé írjuk oda, mi a legrosszabb, amit egy rosszindulatú dokumentum hatására megtehet. Ahol a válasz kényelmetlen, ott szűkíteni kell az eszközt, a jogot vagy a jóváhagyás nélküli mozgásteret.

Ellátási lánc, adat- és modellmérgezés, vektoradatbázisok

Egy LLM-alkalmazás ellátási lánca hosszabb a megszokottnál. A szoftverfüggőségeken túl ide tartozik az előtanított modell, a finomhangolás során készült adapter, a tanító- és értékelő adatkészlet, valamint a modellt kiszolgáló keretrendszer. Nyilvános modelltárakból bárki tölthet le és tölthet fel modellt, ezért a származás ellenőrzése itt ugyanolyan fontos, mint egy nyílt forrású csomagnál. Egyes modellfájl-formátumok betöltéskor kódot futtathatnak, így egy ismeretlen forrásból származó modell megnyitása is kockázat. Segít a szoftver-anyagjegyzék (SBOM) vezetése a modellekről és adatkészletekről is, a modellek licencfeltételeinek ellenőrzése és a kódot nem futtató tárolási formátum használata.

A mérgezés a modell tartalmát célozza. A támadó manipulált adatot juttat az előtanításhoz, a finomhangoláshoz vagy a beágyazásokhoz, és ezzel torzítja a viselkedést, vagy rejtett kiváltó jelet épít be, amelyre a modell később előre meghatározott módon reagál. Ilyen hátsó ajtót utólag nehéz észrevenni, mert a modell a szokásos teszteken rendesen viselkedik. A védekezés az adatok eredetének nyomon követésével, a beérkező adatok ellenőrzésével és a modell célzott, ellenséges szemléletű tesztelésével kezdődik.

A nyolcadik tétel a keresésre épülő (RAG) rendszerekről szól, amelyek a dokumentumokat számvektorokká alakítva egy vektoradatbázisban tárolják. Ellenük jogosultság szerinti keresés és particionálás, a betöltött források ellenőrzése és a lekérdezések naplózása véd, a jellemző hibák pedig ezek:

  • a vektortárban nincs jogosultsági szűrés, így egy felhasználó kérdésére más osztály vagy más ügyfél dokumentumai is visszajönnek;
  • a tudásbázisba ellenőrzés nélkül kerülnek dokumentumok, és egy fehér betűvel írt, láthatatlan utasítás így bejut a modell kontextusába;
  • a beágyazásokból megfelelő technikával részben visszaállítható az eredeti szöveg, ezért a vektortár ugyanolyan érzékeny, mint maguk a dokumentumok.

Félretájékoztatás és korlátlan erőforrás-használat

A nyelvi modell a statisztikailag valószínű folytatást írja meg, és ez nem mindig igaz. A hallucináció önmagában még csak hibás szöveg, a gond akkor kezdődik, amikor valaki ellenőrzés nélkül dönt rá. Az OWASP ezért a túlzott bizalmat is ehhez a tételhez köti. Fejlesztésben különösen kellemetlen eset, amikor a modell nem létező szoftvercsomagot ajánl, és a támadó éppen ilyen néven tölt fel kártékony csomagot a nyilvános tárolóba.

A kockázatot forrásmegjelölő válaszok, megbízható dokumentumokra épülő keresés, a fontos kimenetek emberi átnézése és a generált kód szokásos ellenőrzése csökkenti. A felületen is jelezni kell, hogy a válasz gépi és tévedhet.

Az utolsó tételnél abból kell kiindulni, hogy a modell futtatása erőforrás-igényes: egy nagyon hosszú bemenet, egy önmagát újrahívó ágens-hurok vagy tömeges automatikus lekérdezés lelassíthatja, leállíthatja vagy feleslegesen terhelheti a szolgáltatást. Ugyanide tartozik a modell kimásolása: elég sok kérdés-válasz párral egy másik modell betanítható úgy, hogy hasonlóan viselkedjen. Védelmet a bemenet méretének korlátozása, a felhasználónkénti kvóta és sebességkorlát, az időtúllépés, az ágensek lépésszámának felső határa és a szokatlan használati minták figyelése ad.

Hogyan használható a lista egy felülvizsgálatnál

A tíz tétel akkor hasznos, ha egy konkrét rendszer rajzára vetítjük. Az első lépés ezért az adatfolyamok feltérképezése: honnan érkezik bemenet (felhasználó, feltöltött fájl, web, e-mail, másik rendszer), mit lát a modell (rendszerprompt, tudásbázis, beszélgetési előzmény), milyen eszközöket hívhat, és hova kerül a kimenete. Ezután tételenként feltehetők a kérdések:

  1. Melyik bemeneti csatornán érkezhet olyan szöveg, amelyet nem a felhasználó írt, és mi történik, ha utasítást tartalmaz?
  2. Milyen jogosultsággal olvas a rendszer, és a felhasználó csak azt kapja-e vissza, amihez egyébként is hozzáfér?
  3. Honnan származnak a modellek, adapterek és adatkészletek, és van-e róluk nyilvántartás?
  4. Ki és hogyan ellenőrzi a tanításhoz és a tudásbázishoz kerülő adatot?
  5. Hol jelenik meg vagy hol fut tovább a kimenet, és ott kódolják, szűrik vagy validálják-e?
  6. Milyen eszközöket hívhat az ágens, milyen hatókörrel, és melyik műveletnél kell emberi jóváhagyás?
  7. Van-e a rendszerpromptban olyan adat vagy szabály, aminek kiszivárgása kárt okozna?
  8. Szűr-e jogosultság szerint a vektortár, és elkülönülnek-e a különböző felhasználói körök adatai?
  9. Ellenőrzi-e valaki a döntést támogató válaszokat, és látja-e a felhasználó a forrást?
  10. Van-e kvóta, sebességkorlát, időtúllépés és lépésszám-korlát?

A lista az AI-specifikus réteget fedi le. A modell ugyanúgy szervereken, hálózaton, identitáskezelő rendszeren és naplózáson fut, mint bármely más alkalmazás, és ezek hibái itt is érvényesek. A hagyományos alkalmazásbiztonsághoz az OWASP saját ellenőrzési szabványa (ASVS) használható, a szervezeti szintű AI-kockázatkezeléshez a NIST AI Risk Management Framework (NIST AI 100-1, 2023), a támadási technikák rendszerezéséhez pedig a MITRE ATLAS tudásbázis. Az átnézést érdemes megismételni, amikor a rendszer új modellt, új adatforrást vagy új eszközt kap, mert ezek mindegyike megváltoztatja a kockázati képet.

Kapcsolódó szolgáltatás: LLM és AI-ágens infrastruktúra biztonsági felülvizsgálata →

Kapcsolat

Készen áll a kritikus rendszerei védelmére?

Szakértőink felmérik biztonsági helyzetét, és egy szervezetéhez illő útitervet dolgoznak ki.

Az ARLITECH gödöllői irodája

Látogasson meg minket

Gödöllői irodánkban személyesen is várjuk.

Cím
Centrum Irodaház, 2100 Gödöllő, Dózsa György út 13, 3. emelet 309
Helyi ügyfélfogadás
H–P 9:00–17:00
Útvonaltervezés (új lapon nyílik)