Brauser kui tagauks: kliendipoolne LLM-i salajane väljavõte on demüstifitseeritud
Liiga kaua oleme käsitlenud tehisintellekti turvahoiatusi kui kaugeid ohte või akadeemilisi uudishimu. Oleme kuulnud kiirest süstimisest, jailbreakidest ja andmelekkest vaiksetes toonides, millele sageli järgneb õlgu kehitamine ja "saame asjani". Hiljutised interaktiivsed meeleavaldused on aga selle mugava illusiooni purustanud. See ei ole enam teoreetiline haavatavus; see on reaalajas, brauseripõhine kliendipoolne ärakasutamine tundliku teabe hankimiseks suurtest keelemudelitest (LLM) [2]. Kui kasutate LLM-i toega rakendusi, eriti kõike, mis on suunatud veebile, muutus teie "tulevikuprobleem" lihtsalt väga aktuaalseks, väga avalikuks ja potentsiaalselt väga piinlikuks vastutuseks.
See ei ole veel üks üldine pealkiri "AI on riskantne". See on konkreetne, käegakatsutav demonstratsioon selle kohta, kuidas pahatahtlik tegutseja saab ainult oma brauserit kasutades sundida teie LLM-i avaldama tundlikku teavet. Mõelge sellele korraks. See ei puuduta keerulisi serveripoolseid rünnakuid ega sügavat mudeli enesevaatlust. See puudutab interaktsioonikihti – teie rakenduse esiukse –, mida kasutatakse mõne hoolikalt koostatud tegelaskujuga. See on digitaalne vaste sellele, et keegi koostab teie väidetavalt turvalisele vestlusbotile õige fraasi ja annab kohusetundlikult üle kriitilised andmed, sageli osade kaupa.
Mudeli turvalisuse illusioon
Paljud ettevõtted on investeerinud palju "turvalistesse" LLM-idesse, kas peenhäälestades patenteeritud mudeleid või tuginedes eeldatavate kaitsepiiretega ettevõtte tasemel API-dele. Kaudne eeldus on, et kui mudel ise on vastupidav, pärib selle peale ehitatud rakendus selle turvalisuse. Hiljutised meeleavaldused paljastavad selle ohtliku eksiarvamusena. Haavatavus ei peitu mudeli põhiluures ega selle koolitusandmetes; see on liideses, mille selle ümber ehitame [1]. See on klassikaline "tugeva varavõlvi, õhuke välisukse" probleem. Teil võib olla maailma kõige arenenum ja karmim LLM, kuid kui teie rakenduse sisendparser on naiivne või teie väljundfilter puudub, jätate sisuliselt kriitilise teabe kõigile kättesaadavaks.
See "kiire süstimise" tehnika on eriti murettekitav, kuna see kasutab LLM-i loomupärast olemust: selle võimet järgida juhiseid ja täita mustreid. Sisestades kasutaja sisendisse hoolikalt koostatud eesliite, saab ründaja manipuleerida mudeli sisemise olekuga, sundides seda avaldama teavet, mille jaoks see pole kunagi mõeldud [3]. "Ühebitine" ehk iteratiivne aspekt on siin ülioluline. See tähendab metoodilist, kontrollitud väljafiltreerimist, mitte lihtsalt kaootilist andmeprügi. Kujutage ette ründajat, kes küsib iteratiivselt: "Kas saladuse esimene märk on "A"?" siis "Kas see on B?" ja nii edasi. See on aeglane, jah, kuid see on ka uskumatult tõhus ja seda on raske tuvastada, kui te seda konkreetselt ei otsi.
Teie brauser, nende relv
Asjaolu, et see on brauseripõhine ärakasutamine, muudab mängu täielikult. See tähendab:
- Madal sisenemisbarjäär: igaüks, kellel on elementaarsed veebiarenduse oskused ja brauser, võib seda proovida. Spetsiaalseid tööriistu ega sügavaid AI-teadmisi pole vaja.
- Kliendipoolne täitmine: rünnak pärineb kasutaja masinast, mistõttu on võrgu serval raskem eristada kasutaja seaduslikust sisendist.
- Kohe oht: kui teie LLM-rakendus on aktiivne ja sellele pääseb juurde veebiliidese kaudu, on see juba selle vektori suhtes haavatav. See ei ole tulevane plaaster; see on praegune hädaolukord.
Mõelge tagajärgedele: patenteeritud koodilõigud, sisemine dokumentatsioon, kliendiandmed, API võtmed või isegi teie LLM-i käitumise peen manipuleerimine, et levitada valeinformatsiooni või luua kahjulikku sisu. Seda kõike saab lihtsa tekstikasti abil pisut vaevaliselt välja võtta või mõjutada.
Vastutus on teie
Mudelipakkujatele, nagu OpenAI või Google, ei ole see probleem järgmises mudelivärskenduses parandada. See on rakenduse turvalisuse probleem ja vastutus leevendamise eest langeb otseselt neid süsteeme juurutavate arendajate, turvameeskondade ja CTO-de õlgadele. Teie LLM on võimas, kuid lõppkokkuvõttes naiivne mootor. See teeb seda, mida kästakse, isegi kui need juhised on peidetud näiliselt kahjutu kasutaja sisendis.
Niisiis, mida sa teed nüüd?
Kohesed vastumeetmed:
- Agressiivne sisendi puhastamine: see läheb kaugemale SQL-i süstimise või XSS-i takistamisest. Peate hoolikalt uurima iga tegelast, kes oma LLM-i sisestab. Otsige mustreid, mis viitavad kiirele süstimisele, ebatavalistele märgijadadele või katsetele eeldatavast vestlusvoost välja murda [4]. See ei tähenda "halbade sõnade" blokeerimist; see on võistlevate viipade tuvastamine. Lisaks põhilisele regex- ja heuristilisele analüüsile rakendage pahatahtlike kavatsuste tuvastamiseks semantilist analüüsi. Kasutage anomaalsete sisendmustrite tuvastamiseks tokeniseerimis- ja manustamisanalüüsi. Kaaluge teisese, väiksema LLM-i või reeglipõhise süsteemi kasutamist, mis on spetsiaalselt koolitatud kiirete süstimiskatsete tuvastamiseks. Otsige mustreid, nagu rollimängujuhised, selgesõnalised andmete eraldamise taotlused või katsed eelmistest juhistest mööda minna.
- Tõhus väljundi filtreerimine ja valideerimine: Ärge kunagi usaldage LLM-i väljundit kaudselt. Enne kui LLM-i loodud teksti kasutajale kuvatakse või mõni muu süsteem seda kasutab, peab see läbima range valideerimiskihi. Kas see sisaldab tundlikke märksõnu? Kas see vastab eeldatavatele vormingutele? Kas see üritab käivitada koodi või avaldada sisemisi süsteemiviipasid? Kui teie LLM peaks tegema dokumendist kokkuvõtte, kuid see hakkab loendama failiteid, on teil probleem.
- Kihiline viipade projekteerimine: kuigi see pole täielik lahendus, võivad hästi läbimõeldud süsteemiviibad ja vähesed näited aidata soovitud käitumist tugevdada ja muuta ründaja jaoks mudeli kaaperdamise raskemaks. Siiski mõista, et kiirest inseneritööst üksi ei piisa; see on sügav kaitse, mitte esmane kilp.
- Vähiim privileeg LLM-i interaktsioonidele: Kas teie LLM vajab tõesti juurdepääsu kõikidele andmetele, mida tal võidakse paluda avaldada? Rakendage ranget juurdepääsukontrolli. Kui LLM peaks vastama ainult küsimustele avaliku dokumentatsiooni kohta, veenduge, et tal poleks programmilist juurdepääsu sisemistele andmebaasidele ega tundlikele API-dele.
- Jälgimine ja anomaalia tuvastamine: peate aktiivselt otsima ebatavalist LLM-i käitumist. Teatud tüüpi päringute hüpped, tavapärastest mustritest erinevad väljundid või korduvad katsed teavet hankida peaksid käivitama kohesed hoiatused.
See ei puuduta enam laiaulatuslikku tehisintellekti turvalisust. See puudutab teie LLM-rakenduste interaktsioonikihi kaitsmist konkreetse, demonstreeritud ja koheselt kasutatava ründevektori vastu. Oleme loonud neid uskumatuid võimsaid süsteeme, mille liidese turvameetmed on sageli ebapiisavad. Hiljutised meeleavaldused on meile täpselt näidanud, kui lihtne on neid lünki ära kasutada. Teoreetiliste arutelude aeg on möödas. LLM-i rakenduste kaitsmiseks on vaja viivitamatult tegutseda.
Allikad
[1] OWASP Top 10 suurte keelemudelite rakenduste jaoks – https://owasp.org/www-project-top-10-for-large-language-model-applications/ [2] Lakera Gandalf: Interactive Prompt Injection Challenge – https://gandalf.lakera.ai/ [3] Kiire süstimise rünnakud | Veebiturbeakadeemia – https://portswigger.net/web-security/llm-attacks/prompt-injection [4] Mis on kiire süstimine ja kuidas seda vältida? - https://www.tenable.com/blog/what-is-prompt-injection-and-how-to-prevent-it