Безопасность 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 экспортировать конфиденциальные записи клиентов перед генерацией ответа.

Как защититься от косвенных промпт-инъекций

Промпт-инъекции обычно следует обрабатывать на уровне хоста. Внешний контент должен быть помечен как ненадежный, а запросы на конфиденциальную информацию должны требовать осознанного одобрения со стороны человека (human-in-the-loop). Также может быть полезно тестирование на проникновение, включающее вызов вредоносных документов или данных для проверки реакции хоста и LLM.

Угроза № 2: Отравление инструментов и rug pulls

В ходе атаки с отравлением инструментов (tool poisoning) вредоносный код добавляется в описание или схему инструмента MCP. Это потенциально может повлиять на LLM на этапе обнаружения, когда MCP впервые предоставляет доступные инструменты.

Rug pull — это особый тип отравления инструментов, при котором изменяются утвержденные метаданные. Эта форма отравления инструментов может изменить то, как модель использует доверенные инструменты, вместо прямого вызова вредоносного инструмента.

Как защититься от отравления инструментов и rug pulls

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

Угроза № 3: Чрезмерные полномочия

Пользователи часто предоставляют серверам MCP и подключенным LLM (через хост) больше прав, чем необходимо для выполнения задачи. Например, права на запись, когда было бы достаточно прав только на чтение, или полный доступ к внутренней файловой системе (например, Google Drive).

Это бесконтрольное расширение прав может увеличить радиус поражения других уязвимостей, таких как вызовы вредоносных инструментов. Часто права «суммируются», когда пользователи наделяют себя привилегиями в ходе повседневной работы с ИИ-инструментами на предприятии (накопление привилегий).

Как защититься от чрезмерных полномочий

Самый прямой способ защиты от этой проблемы — ограничить разрешения и области видимости OAuth (чтение, запись, полный доступ и т. д.). Одобрение со стороны пользователя, особенно для чувствительных операций, является важной частью этого процесса, но права также должны контролироваться на системном уровне (операционная система, хост MCP и сервер).

Угроза № 4: Слабая аутентификация и авторизация

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

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

Как защититься от слабой аутентификации и авторизации

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

Угроза № 5: Утечки и злоупотребление учетными данными

Серверы MCP регулярно используют такие учетные данные, как ключи API и токены доступа OAuth, для подключения к внешним службам. Если они будут раскрыты или использованы не по назначению, злоумышленники смогут получить доступ к конфиденциальным данным и функциональности.

Одним из примеров является сквозная передача токенов (token passthrough), когда сервер MCP пересылает токен доступа другой службе без проверки того, действительно ли он предназначен для принимающей службы. Это, в свою очередь, может привести к утечке, если принимающая служба обладает неадекватной защитой.

Как защититься от утечек и злоупотребления учетными данными

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

Угроза № 6: Атаки типа «сбитый с толку заместитель»

Атака типа «сбитый с толку заместитель» (confused-deputy attack) происходит, когда злоумышленник обманом заставляет доверенное приложение использовать свои права для выполнения действия, не авторизованного легитимным пользователем. В этом случае сервером-заместителем выступает сервер 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 attacks)

При атаке смешивания злоумышленник обманом заставляет MCP-клиент отправить код авторизации на вредоносный сервер авторизации, расположенный между клиентом и MCP-сервером. Сервер авторизации — это приложение, которое выдает токены доступа OAuth после проверки того, что запрошенный доступ разрешен.

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

Как защититься от атак смешивания

MCP-клиенты должны проверять подлинность сервера авторизации на протяжении всего процесса OAuth. В частности, они должны сверять идентификатор издателя сервера (iss) с ожидаемой идентификацией и отклонять несоответствия.

Угроза № 11: Компрометация локального MCP-сервера

Многие MCP-серверы работают на локальной машине пользователя. Пользователь может установить сервер от стороннего разработчика или собрать его самостоятельно. Если злоумышленник сможет скомпрометировать этот локальный MCP-сервер, он потенциально получит доступ к большей части локальной системы.

Существуют различные способы получения доступа. Злоумышленники могут распространять вредоносный сервер под видом легитимной интеграции, изменять конфигурацию MCP-хоста так, чтобы он выполнял вредоносную команду, или получать доступ к MCP-серверу, работающему в среде с недостаточными средствами контроля безопасности (например, через DNS-rebinding, который заставляет браузер отправлять запросы к сервису localhost).

Как защититься от компрометации локального MCP-сервера

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

Уязвимости MCP — это часто старые угрозы в новом обличье

Уязвимости MCP часто проистекают из нового применения устоявшихся рисков и методологий атак. MCP предоставляет злоумышленникам новые способы эксплуатации этих уязвимостей через взаимодействие LLM, MCP-серверов и внешних сервисов.

Конечно, существуют и специфичные для MCP угрозы. Тем не менее стоит помнить, что стандартные протоколы безопасности — такие как обеспечение строгой авторизации, использование доверенных поставщиков и защита от инъекций промптов — позволят надежно защитить любую реализацию MCP.