Защитите свою систему MCP: 11 распространенных рисков и способы защиты от них

В этом руководстве рассказывается о безопасности MCP: об 11 распространенных рисках для систем MCP — от косвенной промпт-инъекции до компрометации локального сервера — и о практических мерах защиты от каждого из них.

Diagram of how MCP works: the MCP host (the AI app) sends tool requests through an MCP client to an MCP server, which offers its tools and returns results to the host.

Риски 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 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.