Ad
Искусственный интеллект

Девять из девяти: ИИ-скрипты провалили проверку безопасности

Маша Даровская
By Маша Даровская , IT-редактор и автор
Девять из девяти: ИИ-скрипты провалили проверку безопасности
Обложка © Anonhaven

Исследователи проверили девять Python-скриптов, созданных ChatGPT, Microsoft Copilot и Google Gemini для обычных офисных задач. Claude Code обнаружил проблемы безопасности в каждом файле. Среди находок оказались подделка серверных запросов, обход ограничений файловой системы, внедрение данных в письма и атаки через символические ссылки.

Результат выглядит тревожно, но не доказывает, что любой код от этих сервисов содержит эксплуатируемые уязвимости. В эксперимент вошли всего девять программ, каждое задание выполнялось один раз, а проверку проводила другая языковая модель. Авторы не подтверждали находки вручную, статическими анализаторами или практическими атаками в лабораторной среде. Работа опубликована 22 июля 2026 года как препринт на arXiv и ещё не прошла рецензирование научным журналом.

Работу подготовили Шанна Кан и Джон Гастингс из Колледжа компьютерных и кибернетических наук Биком при Университете штата Дакота. Исследование посвящено небольшим программам, которые могут создавать сотрудники без подготовки в разработке и информационной безопасности.

Авторы сначала попросили ChatGPT, Copilot и Gemini предложить распространённые задачи для автоматизации офисной работы. Claude объединил ответы и удалил повторы, после чего исследователи случайно выбрали три направления из шести: сбор данных с сайтов, почтовые рассылки и сортировку файлов.

Первый скрипт должен был получать с указанного пользователем сайта названия товаров, цены и сведения о наличии. Программа автоматически переходила между страницами, принимала CSS-селекторы во время запуска и сохраняла результат в CSV. Для работы требовались Python 3.10, BeautifulSoup и библиотека requests.

Второе задание предусматривало чтение имён и адресов из CSV, заполнение текстового шаблона и отправку писем через SMTP. Настройки сервера и учётные данные хранились в файле .env, а сведения об отправленных сообщениях записывались в обычный журнал.

Третий скрипт следил за выбранной папкой, сортировал новые файлы по расширениям, добавлял к именам временную метку и переносил документы в каталоги из конфигурационного файла JSON. Программа также вела текстовый журнал операций.

Каждый сервис получил три одинаковых запроса. Всего получилось девять программ: по одному сборщику данных, почтовому скрипту и сортировщику файлов от ChatGPT, Copilot и Gemini. Код сохраняли без ручных исправлений, а запрос выполняли только один раз. Такой порядок должен был воспроизвести поведение неопытного пользователя, который запускает первый работоспособный результат.

Все девять программ справлялись с заявленными задачами. Сборщики получали данные, почтовые программы отправляли сообщения, а файловые наблюдатели сортировали документы. Исправная работа при этом не означала, что код безопасен.

Для анализа исследователи использовали Claude Code с расширением для Visual Studio Code 1.113.0 и подпиской Claude Pro. Каждый файл передавался агенту отдельно с коротким запросом: найти распространённые проблемы безопасности и объяснить их, но перечислить не больше пяти.

Claude Code сообщил о максимально разрешённых пяти проблемах в каждом файле. Так появились 45 записей — результат ограничения запроса, а не доказательство, что в каждом скрипте было ровно пять уязвимостей. Дополнительные ошибки могли не попасть в ответы.

Затем тому же Claude Code поручили объединить результаты и убрать повторы. После такой обработки осталось 17 классов проблем. Авторы присвоили им оценки CVSS 3.1 и сопоставили находки с категориями OWASP Top 10 и техниками MITRE ATT&CK.

Ручной проверки получившегося списка не проводилось. Отдельный специалист не подтверждал, что Claude Code правильно понял каждый участок программы, а готовые сценарии атак не запускались. Поэтому исследователи предлагают дополнить будущие работы ручным аудитом, формальной проверкой и динамическими испытаниями.

Все три скрипта для сбора данных принимали адрес страницы от пользователя без достаточных ограничений. Исследователи классифицировали это как подделку серверных запросов, или SSRF.

При SSRF программа сама обращается к адресу, контролируемому атакующим. Вместо обычного интернет-магазина ей можно передать адрес внутреннего сервера, локального интерфейса или облачной службы метаданных. Запрос отправится с компьютера, на котором запущен скрипт, и сможет пройти туда, куда внешнему пользователю прямого доступа нет.

Авторы оценили найденный вариант SSRF в 9,3 балла по шкале CVSS. Такой балл показывает возможный ущерб в выбранном ими сценарии, но не учитывает реальную конфигурацию сети, межсетевые экраны, прокси-серверы и права конкретного пользователя. Сами исследователи называют оценки разумным худшим сценарием, а не точным прогнозом последствий каждой установки.

В сборщиках также встречались запросы без ограничения времени ожидания и переходы по страницам без надёжного предела. Медленный сервер мог удерживать соединения, а ошибочная пагинация — расходовать память, сетевые ресурсы или лимиты сайта.

OWASP рекомендует разрешать обращения только к ожидаемым адресам, проверять схему и получателя запроса, блокировать ненужный доступ во внутреннюю сеть и использовать сетевую политику «запрещено по умолчанию». Простая проверка наличия https в начале строки не закрывает перенаправления, подмену DNS и особенности разбора адресов.

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

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

Во всех трёх почтовых программах Claude Code также отметил слишком широкую обработку исключений. Один общий блок мог скрывать разные сбои — от проблем соединения до ошибок авторизации. Программа продолжала выглядеть рабочей, а важная причина отказа терялась в общем сообщении журнала.

Файловые скрипты доверяли путям, записанным в конфигурационном JSON. Изменённая настройка могла направить документы в каталог за пределами ожидаемой рабочей области. Авторы отнесли такое поведение к обходу каталогов и недостаточной проверке путей.

Все три программы также получили замечания из-за работы с символическими ссылками. Такая ссылка выглядит как обычный файл или папка, но ведёт к другому объекту файловой системы. При неосторожной проверке атакующий может заменить ожидаемый каталог ссылкой и перенаправить перемещение документов в другое место.

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

Авторы также отметили запись чувствительных сведений в текстовые журналы и отсутствие ограничений на объём обрабатываемых данных. Практический ущерб этих недостатков зависит от содержимого файлов и места хранения журналов.

После удаления повторов Claude Code сформировал список из 17 классов проблем. Девять из них встретились в программах всех трёх сервисов, а 14 — как минимум у двух. Лишь три класса оказались уникальными для одного поставщика. Всего авторы насчитали 13 классов проблем в трёх скриптах ChatGPT, 14 в трёх программах Copilot и 12 в результатах Gemini. Суммарные взвешенные оценки CVSS различались менее чем на 10%.

Авторы умножили оценки CVSS на число сервисов, в программах которых встречалась конкретная проблема. По их расчёту, 11 из 17 классов сформировали около 80% взвешенного риска. В верхнюю часть списка вошли внедрение в шаблоны, SSRF, подмена заголовков электронной почты и обход каталогов.

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

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

Авторы ссылаются на отдельный эксперимент с GPT-моделями, где добавление требований безопасности в запрос снижало частоту уязвимостей на величину до 56%. Речь идёт о сокращении относительно исходного результата, а не о гарантии, что безопасными станут 56% программ.

Подсказка может напомнить модели о проверке входных данных, правах доступа и обработке ошибок. Она не заменяет аудит: модель способна пропустить проблему, неправильно применить защиту или создать новый дефект во время исправления.

Вопросы и ответы

Действительно ли все программы ChatGPT, Copilot и Gemini уязвимы?

Нет. Исследователи проверили только девять скриптов — по три от каждого сервиса. Claude Code сообщил о проблемах во всех девяти файлах, но результат нельзя распространять на весь создаваемый этими системами код.

Уязвимости удалось реально использовать?

Нет. Динамические атаки в лаборатории не проводились. Исследование ограничилось разбором кода с помощью Claude Code и теоретическим описанием возможных последствий.

Откуда взялись 45 находок?

Запрос разрешал Claude Code перечислить не больше пяти проблем на файл. Агент каждый раз достигал этого предела: девять файлов дали 45 записей. После удаления повторов осталось 17 классов.

Что означают числа 13, 14 и 12?

Это количество классов проблем, встретившихся в трёх программах каждого сервиса: 13 у ChatGPT, 14 у Copilot и 12 у Gemini. Это не число ошибок в одном скрипте.

Какой сервис оказался безопаснее?

Исследование не позволяет выбрать победителя. Результаты близки, выборка мала, а статистическая значимость различий не проверялась.

Что такое SSRF?

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

Достаточно ли попросить ИИ написать безопасный код?

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

Можно ли поручить проверку другой языковой модели?

ИИ-агент полезен как первый фильтр, но не должен быть единственным проверяющим. Авторы исследования указывают, что Claude Code не равен формальному анализу или ручному аудиту специалиста.

Есть новость? Станьте автором.

Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.