Прелистувачот како задна врата: демистифицирана тајна екстракција на LLM од страна на клиентот
Предолго ги третиравме „безбедносните предупредувања за вештачка интелигенција“ како далечни закани или академски куриозитети. Слушнавме за брзо вбризгување, џеилбрејкови и истекување на податоци во придушени тонови, често проследено со кревање раменици и „ќе дојдеме до тоа“. Меѓутоа, неодамнешните интерактивни демонстрации ја урнаа таа удобна илузија. Ова веќе не е теоретска ранливост; тоа е експлоатација во живо, базирана на прелистувач, од страна на клиентот за извлекување чувствителни информации од големи јазични модели (LLM) [2]. Ако имплементирате апликации напојувани со LLM, особено сè што се соочува со веб-страница, вашиот „иден проблем“ стана многу присутен, многу јавен и потенцијално многу непријатна одговорност.
Ова не е уште еден генерички наслов „Ви е ризичен“. Ова е специфична, опиплива демонстрација за тоа како злонамерен актер, користејќи го само својот прелистувач, може да го принуди вашиот LLM да открие чувствителни информации. Размислете за тоа за момент. Не се работи за сложени напади од страна на серверот или за длабока интроспекција на моделот. Станува збор за слојот на интеракција - самата влезна врата на вашата апликација - да се искористи со неколку внимателно изработени знаци. Тоа е дигитален еквивалент на некој што ја прави вистинската фраза на вашиот наводно безбеден чет-бот, и тој совесно ги предава критичните податоци, често малку по малку.
Илузијата на безбедноста на моделот
Многу претпријатија инвестираа многу во „безбедни“ LLM, или прецизно подесување сопственички модели или потпирајќи се на API-и од типот на претпријатие со наводни заштитни огради. Имплицитната претпоставка е дека ако самиот модел е робустен, апликацијата изградена врз него ќе ја наследи таа безбедност. Неодамнешните демонстрации го изложуваат ова како опасна заблуда. Ранливоста не е во основната интелигенција на моделот или во податоците за обуката; тоа е во интерфејсот што го градиме околу него [1]. Тоа е класичниот проблем „робустен свод, слаба влезна врата“. Можеби го имате најнапредниот, зајакнат LLM во светот, но ако парсерот за влез на вашата апликација е наивен или ако вашиот излез филтер не постои, во суштина оставате критични информации изложени за секој да ги најде.
Оваа техника на „брзо вбризгување“ е особено загрижувачка бидејќи ја користи вродената природа на LLM: неговата способност да ги следи упатствата и комплетните шеми. Со вбризгување на внимателно конструиран префикс во влезот на корисникот, напаѓачот може да манипулира со внатрешната состојба на моделот, принудувајќи го да открие информации за кои никогаш не била наменета [3]. Овде е клучен аспектот „еднобитен“ или итеративен. Тоа подразбира методична, контролирана ексфилтрација, а не само хаотична депонија на податоци. Замислете напаѓач кој постојано прашува: „Дали првиот лик од тајната е „А“? потоа „Дали е „Б“? и така натаму. Тоа е бавно, да, но исто така е неверојатно ефикасно и тешко е да се открие ако не го барате конкретно.
Вашиот прелистувач, нивното оружје
Фактот дека ова е експлоатација базирана на прелистувач целосно ја менува играта. Тоа значи:
- Ниска бариера за влез: Секој со основни вештини за развој на веб и прелистувач може да се обиде ова. Не се потребни специјализирани алатки или длабоко знаење за вештачка интелигенција.
- Извршување од страна на клиентот: Нападот потекнува од машината на корисникот, што го отежнува разликувањето од легитимниот кориснички влез на работ на мрежата.
- Непосредна закана: Ако вашата апликација за LLM е во живо и е достапна преку веб-интерфејс, таа веќе е ранлива на овој вектор. Ова не е иден лепенка; тоа е сегашна вонредна состојба.
Размислете за импликациите: фрагменти од комерцијален код, внатрешна документација, податоци за клиентите, клучеви на API или дури и суптилна манипулација со однесувањето на вашиот LLM за ширење дезинформации или генерирање штетна содржина. На сето ова може да се извлече или да се влијае, малку по макотрпно, преку едноставно поле за текст.
Одговорноста е ваша
Ова не е проблем за провајдерите на модели како OpenAI или Google да го поправат при нивното следно ажурирање на моделот. Ова е проблем со безбедноста на апликациите, а одговорноста за ублажување паѓа директно на рамениците на програмерите, безбедносните тимови и CTO кои ги распоредуваат овие системи. Вашиот LLM е моќен, но на крајот наивен мотор. Ќе го направи она што му е кажано, дури и ако тие инструкции се скриени во навидум безопасниот влез од корисникот.
Па, што правиш сега?
Непосредни контрамерки:
- Агресивна санација на влезот: Ова оди подалеку од спречување на инјектирање SQL или XSS. Треба внимателно да го испитате секој знак што влегува во вашиот LLM. Побарајте шеми што укажуваат на брзо вбризгување, невообичаени секвенци на знаци или обиди да се извлечете од очекуваните разговорни текови [4]. Овде не се работи за блокирање на „лоши зборови“; се работи за идентификација на противнички инструкции. Надвор од основната регекс и хеуристичка анализа, спроведете семантичка анализа за да откриете злонамерни намери. Користете токенизација и анализа на вградување за да идентификувате аномални шеми на внесување. Размислете за користење на секундарен, помал LLM или систем заснован на правила специјално обучен за откривање на брзи обиди за инјектирање. Побарајте шеми како инструкции за играње улоги, експлицитни барања за екстракција на податоци или обиди да се заобиколат претходните инструкции.
- Робусно филтрирање и валидација на излезот: Никогаш не верувајте имплицитно на излезот на LLM. Пред некој текст генериран од LLM да се прикаже на корисник или да се користи од друг систем, тој мора да помине низ ригорозен слој за валидација. Дали содржи чувствителни клучни зборови? Дали се совпаѓа со очекуваните формати? Дали се обидува да изврши код или да открие внатрешни системски потсетници? Ако вашиот LLM треба да резимира документ, но почнува да ги наведува патеките на датотеките, имате проблем.
- Слоевито брзо инженерство: Иако не е целосно решение, добро дизајнираните системски потсетници и неколку примери за снимки може да помогнат да се зајакне посакуваното однесување и да му отежне на напаѓачот да го киднапира моделот. Сепак, разберете дека брзото инженерство само по себе е недоволно; тоа е одбрана во длабочина, а не примарен штит.
- Најмалку привилегија за LLM интеракции: Дали на вашиот LLM навистина му треба пристап до секој податок што можеби ќе биде побарано да го открие? Спроведување на строги контроли за пристап. Ако LLM треба да одговара само на прашања во врска со јавната документација, погрижете се да нема програмски пристап до внатрешни бази на податоци или до чувствителни API.
- Следење и откривање аномалија: Треба активно да барате невообичаено однесување на LLM. Скокови во одредени типови на прашања, излези што отстапуваат од нормалните обрасци или повторени обиди за извлекување информации треба да активираат итни предупредувања.
Повеќе не се работи за широка „безбедност на вештачка интелигенција“. Станува збор за обезбедување на интеракцискиот слој на вашите LLM апликации против специфичен, демонстриран и веднаш искористлив напад вектор. Ги градевме овие неверојатни, моќни системи, често со несоодветни безбедносни мерки на интерфејсот. Неодамнешните демонстрации ни покажаа точно колку е лесно да се искористат овие празнини. Времето за теоретски дискусии е минато. Потребна е итна акција за да се обезбедат апликациите за LLM.
Извори
[1] OWASP Топ 10 за апликации со големи јазични модели — https://owasp.org/www-project-top-10-for-large-language-model-applications/ [2] Лакера Гандалф: Интерактивен предизвик за брзо инјектирање — https://gandalf.lakera.ai/ [3] Промптни напади со инјектирање | Веб безбедносна академија - https://portswigger.net/web-security/llm-attacks/prompt-injection [4] Што е брза инјекција и како да се спречи тоа? — https://www.tenable.com/blog/what-is-prompt-injection-and-how-to-prevent-it