Cele mai multe bug-uri de securitate sunt greșeli. Cineva a uitat să valideze un input. Cineva a lăsat un bucket public. Prompt injection nu este o greșeală. Este o consecință a modului în care funcționează modelele lingvistice.
Un LLM citește instrucțiuni și date prin același canal: textul. Nu are o modalitate fiabilă de a le diferenția. Dacă un atacator poate plasa text oriunde modelul îl va citi, acel text concurează cu promptul tău de sistem. Uneori câștigă.
OWASP clasifică prompt injection ca LLM01, principalul risc pentru aplicațiile LLM, în ambele ediții ale Top 10 pentru Large Language Models. La Zerotak, este și constatarea pe care o raportăm cel mai des atunci când testăm funcționalități AI în producție.
Ce este, de fapt, prompt injection
Comparația la care oamenii apelează cel mai des este SQL injection. Este suficient de apropiată pentru a fi utilă și suficient de diferită pentru a fi periculoasă. În SQL injection, baza de date parsează comenzi și date din același string. Sanitizezi inputul, escape-uiești caracterele, folosești prepared statements, iar clasa de bug-uri dispare.
În prompt injection, modelul interpretează tot ce citește ca fiind potențial instructiv. Nu există prepared statement pentru limbaj natural. Nu există caracter de escape pentru „ignoră ce ți s-a spus mai devreme”.
Injecție directă vs. indirectă
OWASP împarte riscul în două forme. Distincția contează, deoarece acestea au raze de impact foarte diferite.
Direct prompt injection apare atunci când utilizatorul este atacatorul. Acesta introduce instrucțiuni în fereastra de chat care suprascriu promptul de sistem. Dezvăluie configurația. Elimină regulile de siguranță. Comportă-te ca un alt asistent. Utilizatorul atacă o sesiune pe care deja o controlează. De obicei, impactul este limitat la acea sesiune.
Indirect prompt injection apare atunci când conținutul este atacatorul. Modelul citește o sursă externă, iar acea sursă conține instrucțiuni ascunse.
- Un CV în format PDF cu text alb pe fundal alb, care îi spune modelului de screening să recomande candidatul
- Un tichet de suport care instruiește un agent să își trimită contextul către o adresă externă
- O pagină web pe care un asistent cu browsing o rezumă, conținând comenzi într-un bloc de comentarii
- Un document dintr-o bază de cunoștințe RAG, compromis o singură dată, dar recuperat pentru fiecare interogare viitoare
Victima aici nu este atacatorul. Victima este un utilizator legitim al cărui asistent tocmai a citit ceva ostil în numele său.
Aici apar incidentele reale.
De ce devine mai grav în cazul agenților
Un chatbot care își dezvăluie promptul de sistem este jenant. Un agent care îți divulgă baza de date este o breșă.
Impactul prompt injection crește direct proporțional cu ceea ce modelului îi este permis să facă. Adaugă apeluri către tooluri, iar instrucțiunile injectate devin acțiuni.
- Toolurile de citire transformă injecția în exfiltrare de date
- Toolurile de scriere transformă injecția în tranzacții neautorizate
- Execuția de cod transformă injecția în remote code execution, printr-un câmp text
- Contextul multi-tenant transformă injecția în acces între tenant-uri
În engagementurile Zerotak am identificat fiecare dintre aceste cazuri. Tiparul se repetă: echipele tratează LLM-ul ca pe o componentă de încredere aflată în mijlocul unui pipeline neîncrezător. Nu este de încredere. Este un parser care urmează sugestii.
De ce pentestele tradiționale ratează acest lucru
Un pentest convențional de aplicație web mapează endpointuri, testează autentificarea și caută injecții la nivel de protocol. Nimic din toate acestea nu scoate la suprafață prompt injection.
Payloadurile sunt semantice, nu sintactice. Spațiul de input este nelimitat, deoarece este limbaj uman. Un payload care eșuează în engleză poate reuși în base64, într-o limbă cu resurse reduse sau pe parcursul a trei schimburi de conversație în loc de unul singur.
Testarea unei aplicații LLM necesită o metodologie diferită:
- Recon pe prompturi. Maparea fiecărei căi prin care textul ajunge la model. Inputul utilizatorului, documentele recuperate, outputurile toolurilor, fișierele încărcate, câmpurile de metadata.
- Fuzzing semantic. Payloaduri adversariale împotriva fiecărei suprafețe, măsurând abaterea de la comportamentul intenționat, nu codurile de eroare.
- Testarea limitelor de încredere. Poate conținutul recuperat să influențeze instrucțiunile de sistem? Poate outputul unui tool să influențeze următorul apel către un tool?
- Revizuirea nivelului de autonomie. Ce poate face modelul deși nu are nevoie să facă?
- Revizuirea gestionării outputului. Outputul modelului este randat ca HTML, trimis către un shell sau scris într-un query?
Zerotak rulează această testare ca un AI pentest dedicat, mapat la OWASP LLM Top 10 și corelat cu MITRE ATLAS, alături de testarea web tradițională de care aplicația de dedesubt încă are nevoie.
Ce reduce cu adevărat riscul
Nu există o remediere unică. Există controale care se suprapun.
- Separă conținutul neîncrezător. Marchează clar datele recuperate ca date. Reduce rata de succes. Nu o elimină.
- Constrânge modelul. Definește formatele de output așteptate. Respinge orice altceva.
- Aplică principiul least privilege pentru tooluri. Un agent care nu poate șterge înregistrări nu poate fi convins să șteargă înregistrări.
- Tratează outputul ca input neîncrezător. Sanitizează înainte de randare, execuție sau interogare. Gestionarea incorectă a outputului este punctul în care injecția devine exploatare.
- Include un om în flux. Pentru acțiuni ireversibile sau cu valoare ridicată, cere aprobare.
- Testează adversarial, după o cadență. Actualizările modelelor schimbă comportamentul. Un payload blocat trimestrul trecut poate funcționa astăzi.
Ultimul punct este cel pe care echipele îl omit. Măsurile de apărare împotriva prompt injection sunt probabilistice, iar apărările probabilistice deviază în timp.
Rezumatul incomod
Prompt injection nu va dispărea odată cu următoarea versiune de model. Cercetarea privind ierarhia instrucțiunilor progresează. Problema nu este rezolvată. Obiectivul realist nu este un model imposibil de compromis. Este o aplicație în care o injecție reușită nu ajunge la nimic care merită furat.
Aceasta este o problemă de arhitectură, nu o problemă de prompt engineering. Dacă ai lansat o funcționalitate LLM sau urmează să o lansezi, merită să știi la ce poate ajunge un atacator prin ea înainte să afle altcineva.
Zerotak testează aplicații AI și LLM așa cum le abordează atacatorii, de la suprafața prompturilor până la stratul de tooluri.
Scrie-ne la contact@zerotak.com.