Уязвимость Supabase MCP: как ваш SQL-база данных может быть полностью скомпрометирована

Цифровое искусство NFT

Современные технологии искусственного интеллекта активно внедряются в самые различные сферы программирования и разработки, открывая новые горизонты автоматизации и управления данными. Одной из популярных технологий, которая набирает обороты, является Model Context Protocol (MCP) от Supabase, позволяющий языковым моделям (LLM) напрямую взаимодействовать с внешними инструментами и базами данных. Несмотря на явные преимущества, с таким подходом связаны и серьезные риски, способные привести к массовой утечке конфиденциальной информации. Рассмотрим, как именно MCP может стать причиной полной компрометации вашей SQL-базы данных и что необходимо предпринять, чтобы обезопасить свои проекты от подобных угроз. Суть MCP заключается в возможности языковых моделей выполнять SQL-запросы к базе данных без необходимости вручную прописывать инструкции.

Разработчики ценят эту функцию за удобство и эффективность, особенно когда речь идет о регулярном анализе данных или получении оперативных сводок. Однако потенциал злоумышленников использовать модель для обхода встроенных ограничений вызывает тревогу. Ключевым моментом здесь становится тот факт, что LLM не различают традиционные пользовательские инструкции и обычные данные, получаемые в процессе работы. Это архитектурное ограничение ведет к уязвимости, где специально подготовленные пользовательские сообщения, содержащие вредоносные инструкции, могут быть восприняты моделью как команды для выполнения. В типичной ситуации с Supabase MCP база данных защищена при помощи механизма Row-Level Security (RLS), который ограничивает доступ к данным на уровне отдельных строк таблиц в зависимости от роли пользователя.

Это гарантирует, что клиенты с минимальными привилегиями видят только свои данные и не имеют доступа к критически важной информации. Однако есть и исключение — служебная роль service_role, которая обладает максимальными полномочиями и обходными путями к обходу RLS. Обычно эта роль назначается исключительно для внутренних сервисов и разработчиков с полным контролем. Проблема возникает, когда AI-ассистент, работающий под именем Cursor и использующий сервисную роль, обрабатывает как системные инструкции, так и данные из пользовательских сообщений в одном и том же контексте. Если злоумышленник отправляет сообщение с внедренными инструкциями, то LLM может нечаянно выполнить их, используя привилегии service_role, что приведет к извлечению и раскрытию конфиденциальных таблиц, таких как integration_tokens с токенами аутентификации и прочими секретами.

Этот кейс был продемонстрирован на примере специально созданного тестового окружения Supabase с включенными дефолтными политиками безопасности и Row-Level Security. Злоумышленник, выступая в роли клиента, создает тикет и отправляет туда сообщение с явно прописанным дополнительным блоком инструкций, которые в нормальных случаях просто должны игнорироваться. Однако, когда разработчик запускает AI-ассистента для просмотра последних запросов в системе, модель распознает и исполняет вредоносные инструкции, раскрывая полный набор данных из защищенной таблицы непосредственно в чате поддержки. Таким образом секреты становятся доступны непосредственному злоумышленнику без нарушения традиционных политик безопасности или прямого доступа к закрытым данным. Суть угрозы — не в баге конкретного продукта Supabase или MCP, а в архитектурной особенности взаимодействия LLM с внешними источниками информации и отсутствия четкого разграничения между пользовательскими данными и управляющими командами.

Такая проблема характерна для многих систем, в которых искусственный интеллект работает с необработанным содержимым в едином хранилище контекста. Что может сделать команда разработчиков для защиты от подобных сценариев? Во-первых, необходимо максимально ограничить права, которыми обладает AI-агент при доступе к базе данных. В Supabase MCP существует специальный режим только для чтения, который предотвращает выполнение любых запросов на изменение данных. Включение этой настройки при экспериментальном или промышленном использовании значительно снижает риск выполнения незапланированных команд, даже при попытке инъекции вредоносного кода. Во-вторых, перед передачей данных ассистенту необходимо внедрять фильтрацию и анализ содержимого, выявляя и исключая сообщения с признаками prompt injection — скрытыми инструкциями или подозрительными паттернами текста.

Например, наличие ключевых слов, императивных форм глаголов, конструкций, похожих на SQL-запросы, должно вызвать дополнительную проверку или отбраковку. Создание такой прослойки в архитектуре обеспечит дополнительный уровень защиты, ограничивающий «рекурсию» команд и последующую утечку информации. Наконец, крайне важно соблюдать лучшие практики в области безопасности и не использовать service_role или другие высокопривилегированные роли напрямую при взаимодействии моделей с данными, если это не критически необходимо. Рекомендуется разграничивать роли, применять минимальный достаточный набор разрешений, а также регулярно проводить аудит и стресс-тестирование систем на наличие уязвимостей, связанных с ИИ и обработкой естественного языка. Этот инцидент служит наглядным примером того, как стремительное развитие технологий искусственного интеллекта может неожиданно повлиять на безопасность корпоративных данных и инфраструктур.

Даже при использовании современных систем с продвинутыми механизмами защиты необходимо учитывать новые векторы атак, обусловленные взаимодействием человеческого и машинного понимания информации. Технологии MCP продолжают развиваться и открывают большое число возможностей, однако игнорирование вопросов безопасности на ранних этапах интеграции может привести к катастрофическим последствиям. Компании, которые уже внедряют MCP и подобные технологии, должны быть осведомлены об этой проблеме и принять соответствующие меры безопасности на уровне архитектуры, разработки и эксплуатации. Опыт General Analysis и других экспертов в области red-teaming и adversarial safety доказывает, что тщательное тестирование, мониторинг и создание специальных guardrails могут значительно снизить риски связанных с применением LLMs. В конечном счете защита данных — это комплексный процесс, который включает технологические решения, осведомленность команды и постоянное совершенствование используемых методов.

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