Заштитите свој MCP систем: 11 уобичајених ризика и како се заштитити од њих

Ризици MCP-а углавном спадају у три категорије: манипулација LLM-ом, безбједност података и приступа те рањивости инфраструктуре.

Будући да MCP сервери често омогућавају приступ великом броју интерних система, потенцијални безбједносни ризик је висок. Ипак, вјероватноћа у великој мјери зависи од подешавања.

Појединци и предузећа могу предузети бројне кораке како би осигурали да су њихови системи заштићени, а протоколи увијек треба да буду сразмјерни могућностима и подацима које повезани MCP сервери могу открити.

Шта је MCP и шта је безбједност MCP-а?

Model Context Protocol (MCP) је отворени стандард који је креирала компанија Anthropic за повезивање апликација заснованих на LLM-у (или хостова) са спољним системима.

Постоје три основне компоненте MCP система: хост, клијент и сервер. Хост, који је често AI асистент, повезује се са спољним MCP сервером преко клијента. Затим може слати захтјеве за покретање спољних функционалности (алата) или преузимање података (ресурса) или промптова који се додају у контекстни прозор LLM-а.

Увећај

Безбједност MCP-а односи се на протоколе који штите везе и компоненте у MCP систему. Постоји неколико кључних изазова специфичних за MCP, укључујући то што AI апликације често имају агентске могућности, а злонамјерна упутства могу бити уграђена у поруке.

Проблеме стварају и познати изазови који нису специфични за MCP, као што су убацивање промпта, слаба аутентификација и несигурне интеграције трећих страна. Као и сваки рачунарски систем, MCP се за заштиту ослања на комбинацију процедуралних протокола, попут коришћења искључиво поузданих сервера, и техничких контрола, попут API мрежних пролаза.

Колико су озбиљне пријетње по MCP?

MCP је брзо постао популарна LLM технологија и користе га многе организације и апликације намијењене потрошачима. Будући да су MCP сервери програми написани у коду, имају рањивости као и свака друга апликација.

Ипак, када организације користе MCP у контролисаним окружењима, он је углавном безбједан. Постоји велика разлика између изградње система са поузданим серверима и провјереним дозволама и повезивања аутономног агента са десетак непровјерених сервера.

Пријетња бр. 1: Индиректно убацивање промпта

Нападач може поставити упутства намијењена LLM-у унутар документа, веб-странице или излаза алата који MCP сервер враћа. Ако хост дода тај садржај у контекстни прозор, постоји могућност да LLM то погрешно протумачи као стварна упутства.

Штавише, ова упутства на први поглед могу дјеловати сасвим прикладно. На примјер, преузети тикет корисничке подршке може наложити LLM-у да извезе осјетљиве евиденције о клијентима прије него што генерише одговор.

Како се заштитити од индиректног убацивања промпта

Убацивање промпта обично треба рјешавати на нивоу хоста. Спољни садржај треба означити као непоуздан, а захтјеви за осјетљиве информације треба да захтијевају информисано одобрење човјека укљученог у процес. Корисно може бити и безбједносно тестирање у којем се позивају злонамјерни документи или подаци како би се видјело како хост и LLM реагују.

Пријетња бр. 2: Тровање алата и „rug pull“ напади

У нападу тровањем алата, злонамјерни код се додаје у опис или шему MCP алата. То може утицати на LLM у фази откривања, када MCP први пут приказује доступне алате.

Увећај

„Rug pull“ је посебна врста тровања алата у којој се мијењају одобрени метаподаци. Овај облик тровања алата може промијенити начин на који модел користи поуздане алате, умјесто да директно позове злонамјерни алат.

Како се заштитити од тровања алата и „rug pull“ напада

Хост треба да прегледа потпуну дефиницију сваког алата прије употребе и упореди је са листом одобрених поузданих алата, чиме открива све измјене. Провјере параметара могу помоћи да се препознају потенцијално опасне могућности и да се оне означе.

Пријетња бр. 3: Прекомјерне дозволе

Корисници често MCP серверима и повезаним LLM-овима (преко хоста) додјељују више дозвола него што је потребно за задатак. На примјер, дозволе за писање када би било довољно само читање или потпун приступ интерном систему датотека (као што је Google Drive).

Ово постепено ширење дозвола може повећати радијус штете других рањивости, попут злонамјерних позива алата. Уобичајено је да се дозволе „сабирају“ док корисници додјељују привилегије током свакодневног рада са AI алатима у предузећу (акумулација привилегија).

Како се заштитити од прекомјерних дозвола

Најдиректнији начин заштите од овог проблема јесте ограничавање дозвола и OAuth опсега (читање, писање, потпун приступ итд.). Одобрења корисника, нарочито за осјетљиве операције, важан су дио тога, али дозволе треба контролисати и на нивоу система (оперативни систем, MCP хост и сервер).

Пријетња бр. 4: Слаба аутентификација и ауторизација

Аутентификација потврђује идентитет корисника или апликација које се повезују са MCP сервером. Ауторизација одређује којим алатима и ресурсима могу приступити.

Лоше конфигурисани MCP сервери могу прихватати захтјеве или токене без исправне аутентификације корисника или примјене ограничења приступа. Осим тога, украдени акредитиви могу злонамјерним актерима омогућити приступ ако је валидација слаба.

Како се заштитити од слабе аутентификације и ауторизације

Аутентификација заснована на OAuth-у за удаљене MCP сервере, краткотрајни токени и контрола приступа заснована на улогама (RBAS) мјере су које помажу у ублажавању слабе ауторизације. Приступ заснован на улогама користан је јер спречава кориснике да приступе подацима и алатима изван својих дозвола, чак и ако сам сервер има приступ.

Пријетња бр. 5: Цурење и злоупотреба акредитива

MCP сервери рутински користе акредитиве као што су API кључеви и OAuth приступни токени за повезивање са спољним сервисима. Ако су они изложени или злоупотријебљени, нападачи могу добити приступ осјетљивим подацима и функционалностима.

Један примјер је прослеђивање токена (token passthrough), при чему MCP сервер прослеђује приступни токен другом сервису без провјере да ли је он заиста намијењен сервису који га прима. То може довести до цурења ако сервис који прима токен нема адекватну заштиту.

Како се заштитити од цурења и злоупотребе акредитива

Краткотрајни токени уског опсега и ротација акредитива ефикасно ограничавају мјеру у којој злонамјерни актери могу искористити процурјеле податке. API кључеве и акредитиве увијек треба безбједно чувати помоћу менаџера тајни.

Пријетња бр. 6: Напади „збуњеног заступника“

Напад „збуњеног заступника“ дешава се када нападач превари поуздану апликацију да искористи своје дозволе за извршавање радње коју легитимни корисник није овластио. У овом случају, MCP сервер је заступник.

Увећај

Нападач ће искористити рањивост MCP сервера (као што су слабе OAuth провјере) да изврши злонамјерни процес, попут позива алата или преузимања података.

Како се заштитити од напада „збуњеног заступника“

Валидација ауторизације, у којој се за сваки позив алата провјерава да ли припада одређеном кориснику, помаже у ограничавању напада „збуњеног заступника“. Осим тога, осјетљиве радње, као што је извоз података, треба да захтијевају изричито овлашћење.

Пријетња бр. 7: Злонамјерни сервери и компромитоване зависности

MCP сервери могу садржати злонамјерни код (у суштини су спољни програми) или се ослањати на компромитоване зависности, као што су библиотеке трећих страна. Ово је проблем ланца снабдијевања софтвером, а не проблем својствен искључиво MCP-у.

Један једноставан начин на који се то може догодити јесте када нападач дистрибуира интеграцију која дјелује легитимно. Када се подеси, она може красти и поново користити акредитиве, приступати осјетљивим подацима и извршавати неовлашћене операције.

Како се заштитити од злонамјерних сервера и компромитованих зависности

Инсталирајте MCP сервере само из поузданих и провјерених извора. Ако је могуће, прегледајте њихов код и увијек провјерите све спољне зависности. Постарајте се да се сервери редовно ажурирају и закрпе.

Пријетња бр. 8: Фалсификовање захтјева на страни сервера (SSRF)

Фалсификовање захтјева на страни сервера (SSRF) настаје када нападач превари MCP сервер да шаље мрежне захтјеве на интерне адресе којима корисник није намјеравао да приступи.

До тога може доћи када MCP сервер излаже алат који преузима информације са URL адресе. Ако нападач може утицати на URL параметар, може га промијенити у жељену мрежну адресу, као што је интерни API или сервис у облаку. То може довести до тога да се осјетљиви подаци преузму и потенцијално учине доступним

Како се заштитити од фалсификовања захтјева на страни сервера (SSRF)

MCP сервери увијек треба да валидирају URL адресе, блокирају приступ ограниченим интерним мрежним адресама и спрече одлазни мрежни приступ. Преусмјеравања такође треба да поштују овај протокол.

Пријетња бр. 9: Отмица сесије

Отмица сесије подразумијева да нападач преузме контролу над активном везом између MCP клијента и сервера.

На примјер, нападач може украсти идентификатор сесије из лоше заштићене MCP апликације (нпр. хоста или сервера). Ако MCP сервер прихвати тај идентификатор, нападач потенцијално може позивати алате са легитимним дозволама корисника.

Како се заштитити од

Ризик од отмице сесије може се смањити строгом провјером идентитета у свим апликацијама MCP система. Шифровање између MCP клијената и удаљених сервера такође је неопходно како идентификатори сесија не би били откривени.

Пријетња бр. 10: Напади замјене (mix-up)

У нападу замјене, нападач превари MCP клијента да пошаље ауторизациони код злонамјерном ауторизационом серверу који се налази између клијента и MCP сервера. Ауторизациони сервер је апликација која издаје OAuth приступне токене након што провјери да је захтијевани приступ одобрен.

Увећај

Ако се MCP хост повезује са више сервиса од којих сваки користи други ауторизациони сервер, нападач потенцијално може контролисати један од њих (на примјер, регистровањем злонамјерног сервиса) и навести клијента да ауторизациони код који је издао легитимни сервер пошаље злонамјерном серверу. Ова замјена може нападачу омогућити да се лажно представи као овлашћена апликација и добије приступ заштићеним сервисима.

Како се заштитити од напада замјене

MCP клијенти треба да провјеравају идентитет ауторизационог сервера током цијелог OAuth процеса. Конкретно, треба да упореде идентификатор издаваоца сервера (iss) са очекиваним идентитетом и одбаце неподударања.

Пријетња бр. 11: Компромитовање локалног MCP сервера

Многи MCP сервери раде на корисниковом локалном рачунару. Корисник може инсталирати сервер од треће стране или га сам направити. Ако нападач успије да компромитује овај локални MCP сервер, потенцијално може добити приступ великим дијеловима локалног система.

Нападач може добити приступ на различите начине. Може дистрибуирати злонамјерни сервер прерушен у легитимну интеграцију, измијенити конфигурацију MCP хоста тако да издаје злонамјерну команду или приступити MCP серверу који ради у окружењу са недовољним безбједносним контролама, на примјер путем DNS rebinding напада, који наводи прегледач да шаље захтјеве localhost сервису.

Како се заштитити од компромитовања локалног MCP сервера

Изоловање у sandbox окружењу и строги протоколи сагласности важни су при коришћењу локалних MCP сервера. MCP сервере треба инсталирати искључиво од поузданих добављача, а дозволе оперативног система треба да ограниче којим директоријумима могу приступити.

Рањивости MCP-а често су старе пријетње у новом руху

Рањивости MCP-а често потичу из нових примјена познатих ризика и метода напада. MCP нападачима отвара нове начине да искористе ове рањивости кроз интеракције између LLM-ова, MCP сервера и спољних сервиса.

Наравно, пријетње специфичне за MCP постоје. Ипак, вриједи имати на уму да ће стандардни безбједносни протоколи, као што су примјена строге ауторизације, коришћење поузданих добављача и заштита од убацивања промпта, умногоме допринијети заштити сваке MCP имплементације.