Убезпечте свою систему MCP: 11 поширених ризиків і як від них захиститися

Ризики MCP загалом поділяються на три категорії: маніпулювання LLM, безпека даних і доступу та вразливості інфраструктури.

Оскільки сервери MCP часто надають доступ до широкого кола внутрішніх систем, потенційний ризик для безпеки високий. Проте ймовірність значною мірою залежить від налаштувань.

Окремі користувачі та підприємства можуть зробити багато кроків, щоб захистити свої системи, а протоколи завжди мають бути пропорційними до можливостей і даних, які можуть розкрити підключені сервери MCP.

Що таке MCP і безпека MCP?

Model Context Protocol (MCP) — це відкритий стандарт, створений Anthropic для підключення застосунків на основі LLM (або хостів) до зовнішніх систем.

У системі MCP є три основні компоненти: хост, клієнт і сервер. Хост, яким часто є ШІ-асистент, підключається до зовнішнього сервера MCP через клієнт. Після цього він може надсилати запити на запуск зовнішніх функцій (інструментів) або на отримання даних (ресурсів) чи промптів, які додаються до контекстного вікна LLM.

Розгорнути

Безпека MCP — це протоколи, що захищають з’єднання та компоненти в системі MCP. Існує кілька ключових викликів, унікальних для MCP, зокрема те, що ШІ-застосунки часто мають агентні можливості, а в повідомлення можуть бути вбудовані шкідливі інструкції.

Відомі проблеми, не специфічні для 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).

Таке масштабне розростання дозволів може збільшити радіус ураження інших вразливостей, як-от шкідливих викликів інструментів. Дозволи часто «накопичуються», коли користувачі надають привілеї під час щоденної роботи з ШІ-інструментами на підприємстві (накопичення привілеїв).

Як захиститися від надмірних дозволів

Найпряміший спосіб захиститися від цієї проблеми — обмежити дозволи та області доступу OAuth (читання, запис, повний доступ тощо). Важливою частиною цього є схвалення користувачами, особливо для конфіденційних операцій, але дозволи також слід контролювати на системному рівні (операційна система, хост і сервер MCP).

Загроза №4: слабка автентифікація та авторизація

Автентифікація перевіряє особу користувачів або застосунків, що підключаються до сервера MCP. Авторизація визначає, до яких інструментів і ресурсів вони мають доступ.

Неправильно налаштовані сервери MCP можуть приймати запити або токени без належної автентифікації користувачів чи застосування обмежень доступу. Крім того, якщо перевірка слабка, викрадені облікові дані можуть дати зловмисникам доступ.

Як захиститися від слабкої автентифікації та авторизації

Автентифікація на основі OAuth для віддалених серверів MCP, короткочасні токени та керування доступом на основі ролей (RBAS) — усе це заходи, які допомагають знизити ризики слабкої авторизації. Рольовий доступ корисний тим, що не дає користувачам отримувати доступ до даних та інструментів поза межами їхніх дозволів, навіть якщо сам сервер має такий доступ.

Загроза №5: витік і неправомірне використання облікових даних

Сервери MCP регулярно використовують облікові дані, як-от ключі API та токени доступу OAuth, для підключення до зовнішніх сервісів. Якщо їх буде розкрито або використано неправомірно, зловмисники можуть отримати доступ до конфіденційних даних і функцій.

Один із прикладів — наскрізна передача токенів (token passthrough), коли сервер MCP пересилає токен доступу іншому сервісу, не перевіривши, чи справді він призначений для сервісу-отримувача. Це, своєю чергою, може призвести до витоку, якщо сервіс-отримувач має недостатній захист.

Як захиститися від витоку й неправомірного використання облікових даних

Короткочасні токени з вузькою областю дії та ротація облікових даних ефективно обмежують можливості зловмисників використати дані, що потрапили у витік. Ключі API та облікові дані завжди слід надійно зберігати за допомогою менеджера секретів.

Загроза №6: атаки «заплутаного заступника» (confused deputy)

Атака «заплутаного заступника» відбувається, коли зловмисник обманом змушує довірений застосунок використати свої дозволи для виконання дії, яку не авторизував легітимний користувач. У цьому випадку заступником є сервер 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

Під час атаки mix-up зловмисник обманом змушує клієнт MCP надіслати код авторизації на шкідливий сервер авторизації, розташований між клієнтом і сервером MCP. Сервер авторизації — це застосунок, який видає токени доступу OAuth після перевірки того, що запитуваний доступ авторизовано.

Розгорнути

Якщо хост MCP підключається до кількох сервісів, кожен з яких використовує власний сервер авторизації, зловмисник потенційно може контролювати один із них (наприклад, зареєструвавши шкідливий сервіс) і змусити клієнт надіслати код авторизації, виданий легітимним сервером, на шкідливий сервер. Така плутанина може дозволити зловмиснику видати себе за авторизований застосунок і отримати доступ до захищених сервісів.

Як захиститися від атак mix-up

Клієнти MCP мають перевіряти ідентичність сервера авторизації протягом усього процесу OAuth. Зокрема, вони мають звіряти ідентифікатор видавця сервера (iss) з очікуваною ідентичністю та відхиляти невідповідності.

Загроза №11: компрометація локального сервера MCP

Багато серверів MCP працюють на локальному комп’ютері користувача. Користувач може встановити сервер від стороннього постачальника або створити його самостійно. Якщо зловмисник зможе скомпрометувати цей локальний сервер MCP, він потенційно отримає доступ до значної частини локальної системи.

Зловмисник може отримати доступ різними способами. Він може поширити шкідливий сервер, замаскований під легітимну інтеграцію, змінити конфігурацію хоста MCP так, щоб той виконав шкідливу команду, або отримати доступ до сервера MCP, що працює в середовищі з недостатніми засобами контролю безпеки, наприклад через DNS rebinding — техніку, яка обманом змушує браузер надсилати запити до сервісу на localhost.

Як захиститися від компрометації локального сервера MCP

Під час використання локальних серверів MCP важливі ізоляція в пісочниці та суворі протоколи згоди. Сервери MCP слід установлювати лише від довірених постачальників, а дозволи операційної системи мають обмежувати, до яких каталогів вони мають доступ.

Вразливості MCP — це часто старі загрози в новому вбранні

Вразливості MCP часто виникають через нові застосування відомих ризиків і методів атак. MCP відкриває для зловмисників нові способи використовувати ці вразливості через взаємодію LLM, серверів MCP і зовнішніх сервісів.

Звісно, загрози, специфічні для MCP, існують. Проте варто пам’ятати, що стандартні протоколи безпеки, як-от суворе застосування авторизації, використання довірених постачальників і захист від ін’єкцій промптів, значною мірою допоможуть захистити будь-яку реалізацію MCP.