Браўзэр як бэкдор: дэмістыфікацыя сакрэтнага здабывання LLM на баку кліента
Занадта доўга мы разглядалі «папярэджанні бяспекі штучнага інтэлекту» як далёкія пагрозы або акадэмічныя кур'ёзы. Мы чулі пра неадкладную ін'екцыю, уцёкі з турмы і ўцечку даных у ціхіх тонах, за якімі часта ідуць пацісканні плячыма і "мы да гэтага дойдзем". Аднак нядаўнія інтэрактыўныя дэманстрацыі разбурылі гэтую камфортную ілюзію. Гэта ўжо не тэарэтычная ўразлівасць; гэта жывы кліенцкі эксплойт на аснове браўзера для здабывання канфідэнцыйнай інфармацыі з вялікіх моўных мадэляў (LLM) [2]. Калі вы разгортваеце прыкладанні на аснове LLM, асабліва што-небудзь, што звернута да Інтэрнэту, ваша "будучая праблема" стала вельмі актуальнай, публічнай і патэнцыйна вельмі няёмкай адказнасцю.
Гэта не чарговы загаловак "ШІ - гэта рызыка". Гэта канкрэтная, адчувальная дэманстрацыя таго, як зламыснік, выкарыстоўваючы толькі свой браўзер, можа прымусіць ваш LLM раскрыць канфідэнцыйную інфармацыю. Разгледзім гэта на імгненне. Справа не ў складаных атаках на баку сервера або глыбокім самааналізе мадэлі. Гаворка ідзе пра тое, каб узровень узаемадзеяння — самая пярэдняя дзверы вашага прыкладання — выкарыстоўваўся некалькімі старанна створанымі персанажамі. Гэта лічбавы эквівалент таго, як хтосьці стварае правільную фразу для вашага нібыта бяспечнага чат-бота, і ён паслухмяна перадае важныя даныя, часта па крупінках.
Ілюзія бяспекі мадэлі
Шматлікія прадпрыемствы ўклалі значныя сродкі ў "бяспечныя" LLM, альбо наладжваючы прапрыетарныя мадэлі, альбо абапіраючыся на API карпаратыўнага ўзроўню з меркаванымі агароджамі. Няяўная здагадка заключаецца ў тым, што калі мадэль сама па сабе надзейная, то створанае на яе аснове прыкладанне атрымае гэтую бяспеку ў спадчыну. Нядаўнія дэманстрацыі выкрываюць гэта як небяспечнае памылковае меркаванне. Уразлівасць заключаецца не ў асноўных інтэлектуальных дадзеных мадэлі або яе навучальных дадзеных; гэта ў інтэрфейсе, які мы будуем вакол яго [1]. Гэта класічная праблема "надзейнае сховішча, хісткія ўваходныя дзверы". У вас можа быць самы дасканалы, загартаваны LLM у свеце, але калі аналізатар уводу вашага прыкладання наіўны або ваш фільтр вываду не існуе, вы, па сутнасці, пакідаеце крытычную інфармацыю адкрытай для любога.
Гэтая методыка "аператыўнага ўвядзення" выклікае асаблівую заклапочанасць, таму што яна выкарыстоўвае ўласцівую прыроду LLM: яго здольнасць прытрымлівацца інструкцый і поўных шаблонаў. Устаўляючы старанна складзены прэфікс ва ўвод карыстальніка, зламыснік можа маніпуляваць унутраным станам мадэлі, прымушаючы яе раскрываць інфармацыю, для якой яна ніколі не прызначалася [3]. «Аднабітны» або ітэрацыйны аспект тут мае вырашальнае значэнне. Гэта прадугледжвае метадычную, кантраляваную эксфільтрацыю, а не проста хаатычны дамп дадзеных. Уявіце сабе зламысніка, які паўтараецца: "Ці з'яўляецца першым сімвалам сакрэтнага "А"?" затым "Гэта "B"?" і гэтак далей. Гэта павольна, так, але гэта таксама неверагодна эфектыўна і цяжка выявіць, калі вы спецыяльна не шукаеце яго.
Ваш браўзер, іх зброя
Той факт, што гэта браўзерны эксплойт, цалкам змяняе гульню. Гэта азначае:
- Нізкі бар'ер для ўваходу: Любы, хто мае базавыя навыкі вэб-распрацоўкі і мае браўзер, можа паспрабаваць гэта. Ніякіх спецыялізаваных інструментаў або глыбокіх ведаў ІІ не патрабуецца.
- Выкананне на баку кліента: Атака адбываецца з машыны карыстальніка, што робіць яе цяжэй адрозніць ад законнага ўводу карыстальніка на мяжы сеткі.
- Непасрэдная пагроза: Калі ваша праграма LLM працуе і даступная праз вэб-інтэрфейс, яна ўжо ўразлівая для гэтага вектара. Гэта не будучы патч; гэта надзвычайная сітуацыя.
Улічыце наступствы: запатэнтаваныя фрагменты кода, унутраная дакументацыя, дадзеныя кліентаў, ключы API або нават тонкія маніпуляцыі з паводзінамі вашага LLM для распаўсюджвання дэзінфармацыі або стварэння шкоднага кантэнту. Усё гэта можна атрымаць або паўплываць, патроху карпатліва, праз простае тэкставае поле.
Адказнасць ляжыць на вас
Для такіх пастаўшчыкоў мадэляў, як OpenAI або Google, гэта не праблема, якую трэба выправіць у наступным абнаўленні мадэлі. Гэта праблема бяспекі прыкладанняў, і адказнасць за змякчэнне кладзецца непасрэдна на плечы распрацоўшчыкаў, груп бяспекі і тэхнічных дырэктараў, якія разгортваюць гэтыя сістэмы. Ваш LLM - гэта магутны, але ў канчатковым рахунку наіўны рухавік. Ён будзе выконваць тое, што яму загадана, нават калі гэтыя інструкцыі схаваны ў, здавалася б, бяскрыўдных уводах карыстальніка.
Такім чынам, што вы робіце цяпер?
Неадкладныя контрмеры:
- Агрэсіўная дэзінфікацыя ўводу: Гэта выходзіць за рамкі прадухілення ўкаранення SQL або XSS. Вам трэба ўважліва вывучыць кожны сімвал, які паступае ў ваш LLM. Шукайце шаблоны, якія сведчаць аб хуткай ін'екцыі, незвычайных паслядоўнасцях сімвалаў або спробах вырвацца з чаканых патокаў размовы [4]. Гаворка ідзе не пра блакіроўку «непрыстойных слоў»; гаворка ідзе пра выяўленне спаборніцкіх падказак. Акрамя базавага рэгулярнага выразу і эўрыстычнага аналізу, выкарыстоўвайце семантычны аналіз для выяўлення зламысных намераў. Выкарыстоўвайце аналіз токенізацыі і ўбудавання для выяўлення анамальных шаблонаў уводу. Падумайце аб выкарыстанні другаснага, меншага LLM або заснаванай на правілах сістэмы, спецыяльна навучанай выяўляць хуткія спробы ін'екцыі. Шукайце шаблоны, такія як ролевыя інструкцыі, відавочныя запыты на выманне даных або спробы абыйсці папярэднія інструкцыі.
- Надзейная фільтрацыя і праверка вываду: Ніколі не давярайце вынікам LLM безумоўна. Перш чым тэкст, згенераваны LLM, будзе паказаны карыстальніку або выкарыстаны іншай сістэмай, ён павінен прайсці ўзровень строгай праверкі. Ці змяшчае ён канфідэнцыяльныя ключавыя словы? Ці адпавядае гэта чаканым фарматам? Ці спрабуе ён выканаць код або раскрыць унутраныя падказкі сістэмы? Калі ваш LLM павінен абагульніць дакумент, але ён пачынае пералічваць шляхі да файлаў, у вас ёсць праблема.
- Шматузроўневая распрацоўка падказак: Хоць гэта і не поўнае рашэнне, добра прадуманыя сістэмныя падказкі і некалькі прыкладаў могуць дапамагчы ўзмацніць жаданае паводзіны і ўскладніць зламысніку захоп мадэлі. Аднак трэба разумець, што адной толькі хуткай інжынерыі недастаткова; гэта глыбокая абарона, а не асноўны шчыт.
- Найменшыя прывілеі для ўзаемадзеяння LLM: Ці сапраўды ваш LLM мае патрэбу ў доступе да кожнай часткі даных, якія яму патэнцыйна можа быць прапанавана раскрыць? Укараніць строгі кантроль доступу. Калі LLM павінен адказваць толькі на пытанні аб публічнай дакументацыі, пераканайцеся, што ў яго няма праграмнага доступу да ўнутраных баз дадзеных або канфідэнцыйных API.
- Маніторынг і выяўленне анамалій: Вы павінны актыўна шукаць незвычайныя паводзіны LLM. Усплёскі пэўных тыпаў запытаў, вынікі, якія адхіляюцца ад нармальных шаблонаў, або паўторныя спробы атрымаць інфармацыю павінны выклікаць неадкладныя папярэджанні.
Гаворка ўжо не ідзе пра шырокую "бяспеку штучнага інтэлекту". Гаворка ідзе аб абароне ўзроўню ўзаемадзеяння вашых прыкладанняў LLM ад канкрэтнага, прадэманстраванага і неадкладнага вектара атакі. Мы стваралі гэтыя неверагодныя, магутныя сістэмы, часта з недастатковымі мерамі бяспекі на інтэрфейсе. Нядаўнія дэманстрацыі паказалі нам, наколькі лёгка выкарыстоўваць гэтыя прабелы. Час тэарэтычных дыскусій прайшоў. Неабходныя неадкладныя меры для забеспячэння бяспекі праграм LLM.
Крыніцы
[1] Топ-10 OWASP для прыкладанняў вялікай моўнай мадэлі — https://owasp.org/www-project-top-10-for-large-language-model-applications/ [2] Lakera Gandalf: Інтэрактыўная задача хуткай ін'екцыі — 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