Pārlūkprogramma kā aizmugures durvis: klienta puses LLM slepenā iegūšana ir demistificēta
Pārāk ilgi mēs esam traktējuši "AI drošības brīdinājumus" kā tālus draudus vai akadēmiskus kuriozus. Mēs esam dzirdējuši par tūlītēju injekciju, jailbreaks un datu noplūdi klusinātos toņos, kam bieži seko plecu paraustīšana un "mēs tiksim pie tā". Tomēr nesenās interaktīvās demonstrācijas ir sagrāvušas šo ērto ilūziju. Tā vairs nav teorētiska ievainojamība; tā ir tiešraides, pārlūkprogrammas, klienta puses izmantošana sensitīvas informācijas iegūšanai no lielas valodas modeļiem (LLM) [2]. Ja izvietojat ar LLM darbināmas lietojumprogrammas, it īpaši visu, kas vērsts uz tīmekli, jūsu "nākotnes problēma" vienkārši kļuva par ļoti aktuālu, ļoti publisku un, iespējams, ļoti apkaunojošu atbildību.
Šis nav vēl viens vispārīgs virsraksts "AI ir riskants". Šī ir īpaša, taustāma demonstrācija tam, kā ļaunprātīgs dalībnieks, izmantojot tikai savu pārlūkprogrammu, var piespiest jūsu LLM atklāt sensitīvu informāciju. Apsveriet to uz brīdi. Runa nav par sarežģītiem servera puses uzbrukumiem vai dziļu modeļa ieskatu. Tas ir par mijiedarbības slāni — jūsu lietojumprogrammas priekšējām durvīm — tiek izmantots ar dažām rūpīgi izstrādātām rakstzīmēm. Tas ir digitālais ekvivalents tam, ka kāds izveido pareizo frāzi jūsu it kā drošajam tērzēšanas robotam, un tas apzinīgi nodod kritiskos datus, bieži pamazām.
Modeļu drošības ilūzija
Daudzi uzņēmumi ir ieguldījuši lielus ieguldījumus "drošos" LLM, vai nu precizējot patentētus modeļus, vai paļaujoties uz uzņēmuma līmeņa API ar paredzamām aizsargmargām. Netiešais pieņēmums ir tāds, ka, ja pats modelis ir stabils, lietojumprogramma, kas uzbūvēta uz tā, pārmantos šo drošību. Nesenās demonstrācijas atklāj to kā bīstamu nepareizu priekšstatu. Ievainojamība nav modeļa galvenajā izlūkošanas datos vai tā apmācības datos; tas ir interfeisā, ko mēs veidojam ap to [1]. Tā ir klasiskā problēma "izturīga velve, vājas priekšējās durvis". Iespējams, jums ir vismodernākā, izturīgākā LLM pasaulē, taču, ja jūsu lietojumprogrammas ievades parsētājs ir naivs vai izvades filtrs neeksistē, jūs būtībā atstājat svarīgu informāciju, ko var atrast ikviens.
Šī "ātrās injekcijas" tehnika ir īpaši satraucoša, jo tā izmanto LLM raksturīgo dabu: tā spēju sekot instrukcijām un pabeigt modeļus. Ievadot lietotāja ievadē rūpīgi izveidotu prefiksu, uzbrucējs var manipulēt ar modeļa iekšējo stāvokli, liekot tam atklāt informāciju, kurai tas nekad nebija paredzēts [3]. “Viena bita” jeb iteratīvais aspekts šeit ir ļoti svarīgs. Tas nozīmē metodisku, kontrolētu eksfiltrāciju, nevis tikai haotisku datu izgāztuvi. Iedomājieties, ka uzbrucējs iteratīvi jautā: "Vai slepenā "A" pirmā rakstzīme ir?" tad "Vai tas ir "B"?" un tā tālāk. Tas ir lēns, jā, taču tas ir arī neticami efektīvs un grūti pamanāms, ja jūs to īpaši nemeklējat.
Jūsu pārlūkprogramma, viņu ierocis
Fakts, ka šī ir pārlūkprogrammas izmantošana, pilnībā maina spēli. Tas nozīmē:
- Zems ienākšanas šķērslis: Ikviens, kam ir tīmekļa izstrādes pamatprasmes un pārlūkprogramma, to var izmēģināt. Nav nepieciešami īpaši rīki vai dziļas AI zināšanas.
- Klienta puses izpilde: uzbrukums rodas no lietotāja datora, tāpēc ir grūtāk atšķirt to no likumīgas lietotāja ievades tīkla malā.
- Tūlītēji draudi: ja jūsu LLM lietojumprogramma ir tiešsaistē un pieejama, izmantojot tīmekļa saskarni, tā jau ir neaizsargāta pret šo vektoru. Šis nav nākotnes ielāps; tā ir pašreizējā ārkārtas situācija.
Apsveriet sekas: patentēti koda fragmenti, iekšējā dokumentācija, klientu dati, API atslēgas vai pat smalkas manipulācijas ar jūsu LLM uzvedību, lai izplatītu dezinformāciju vai radītu kaitīgu saturu. To visu var iegūt vai ietekmēt, izmantojot vienkāršu teksta lodziņu.
Atbildība ir jūsu
Modeļu nodrošinātājiem, piemēram, OpenAI vai Google, šī problēma nav jālabo nākamajā modeļa atjauninājumā. Šī ir lietojumprogrammu drošības problēma, un atbildība par mazināšanu gulstas uz izstrādātāju, drošības komandu un CTO, kas izvieto šīs sistēmas, pleciem. Jūsu LLM ir spēcīgs, bet galu galā naivs dzinējs. Tas darīs to, kas tam paredzēts, pat ja šīs instrukcijas ir paslēptas šķietami nekaitīgā lietotāja ievadē.
Tātad, ko jūs darāt tagad?
Tūlītēji pretpasākumi:
1. Agresīva ievades sanitizācija: tas pārsniedz SQL injekcijas vai XSS novēršanu. Jums ir rūpīgi jāpārbauda katra rakstzīme, kas ievada jūsu LLM. Meklējiet modeļus, kas norāda uz tūlītēju ievadīšanu, neparastām rakstzīmju sekvencēm vai mēģinājumiem izkļūt no paredzamajām sarunu plūsmām [4]. Tas nav par "slikto vārdu" bloķēšanu; tas ir par pretrunīgu pamudinājumu identificēšanu. Papildus pamata regulārai izteiksmei un heiristiskajai analīzei ieviesiet semantisko analīzi, lai atklātu ļaunprātīgus nolūkus. Izmantojiet marķieru un iegulšanas analīzi, lai identificētu anomālus ievades modeļus. Apsveriet iespēju izmantot sekundāru, mazāku LLM vai uz noteikumiem balstītu sistēmu, kas īpaši apmācīta, lai noteiktu tūlītējus injekcijas mēģinājumus. Meklējiet modeļus, piemēram, lomu spēles norādījumus, skaidrus datu ieguves pieprasījumus vai mēģinājumus apiet iepriekšējos norādījumus. 2. ** Noturīga izvades filtrēšana un apstiprināšana:** Nekad neuzticieties LLM izvadei. Pirms jebkurš LLM ģenerēts teksts tiek parādīts lietotājam vai izmantots citā sistēmā, tam ir jāiziet cauri stingrai validācijas slānim. Vai tajā ir sensitīvi atslēgvārdi? Vai tas atbilst paredzētajiem formātiem? Vai tas mēģina izpildīt kodu vai atklāt iekšējās sistēmas uzvednes? Ja jūsu LLM ir paredzēts apkopot dokumentu, bet tas sāk uzskaitīt faila ceļus, jums ir problēma. 3. Slāņveida uzvedņu inženierija:, lai gan tas nav pilnīgs risinājums, labi izstrādātas sistēmas uzvednes un dažu kadru piemēri var palīdzēt nostiprināt vēlamo darbību un apgrūtināt uzbrucējam modeļa nolaupīšanu. Tomēr saprotiet, ka ar operatīvu inženieriju vien nepietiek; tā ir dziļa aizsardzība, nevis primārais vairogs. 4. Vismazākās privilēģijas LLM mijiedarbībai: vai jūsu LLM patiešām ir nepieciešama piekļuve visiem datiem, kas, iespējams, tiks aicināti atklāt? Ieviesiet stingru piekļuves kontroli. Ja LLM ir jāatbild tikai uz jautājumiem par publisko dokumentāciju, pārliecinieties, ka tai nav programmatiskas piekļuves iekšējām datu bāzēm vai sensitīvām API. 5. Uzraudzība un anomāliju noteikšana: jums ir aktīvi jāmeklē neparasta LLM uzvedība. Konkrētu vaicājumu veidu pieaugumam, izvadēm, kas atšķiras no parastajiem modeļiem, vai atkārtotiem mēģinājumiem iegūt informāciju, ir jāraida tūlītēji brīdinājumi.
Šeit vairs nav runa par plašu "AI drošību". Tas ir par jūsu LLM lietojumprogrammu mijiedarbības slāņa nodrošināšanu pret konkrētu, demonstrētu un nekavējoties izmantojamu uzbrukuma vektoru. Mēs esam veidojuši šīs neticamās, jaudīgās sistēmas, bieži vien ar neatbilstošiem drošības pasākumiem saskarnē. Nesenās demonstrācijas mums precīzi parādīja, cik viegli ir izmantot šīs nepilnības. Teorētisko diskusiju laiks ir pagājis. Lai nodrošinātu LLM lietojumprogrammas, ir jārīkojas nekavējoties.
Avoti
[1] OWASP 10 populārākās lielo valodu modeļu lietojumprogrammas — https://owasp.org/www-project-top-10-for-large-language-model-applications/ [2] Lakera Gendalf: Interactive Prompt Injection Challenge — https://gandalf.lakera.ai/ [3] Tūlītēji injekcijas uzbrukumi | Web drošības akadēmija — https://portswigger.net/web-security/llm-attacks/prompt-injection [4] Kas ir tūlītēja injekcija un kā to novērst? — https://www.tenable.com/blog/what-is-prompt-injection-and-how-to-prevent-it