ИИ пишет рабочий код. Безопасным его делаешь ты.
ИИ-ассистент охотно пишет функционал. Авторизацию, запросы к базе, работу с файлами делает быстро. Вот только «работает» и «защищено» про разное. Второе он сам по себе не делает: его дело выдать функцию, закрывать её от атак никто не просил. Внутри конструктор промтов, который заставляет того же ассистента искать слабые места. Берёшь основной промт, добавляешь нужные блоки, отдаёшь свой код на разбор.
ИИ пишет рабочий код почти всегда. С защитой сложнее.
Я часто разбираю код, который сгенерировал ассистент. Картина повторяется: функция работает, демо проходит, всё выглядит готовым. Потом смотришь, как сделана проверка прав, и по чужому номеру в адресе достаёшь чужие данные. Ассистент не схалтурил. Он сделал ровно то, что просили: «дай функционал». Закрыть систему от того, кто специально ищет дыры, его никто не просил.
Запрос к базе без защиты от подстановки компилируется и работает. Доступ к чужой записи по номеру в ссылке? Фича делает что обещали. А токен, который утёк в лог, вообще никто не замечает: ошибок-то нет. Всё это выглядит нормально ровно до момента, когда код попадёт к тому, кто умеет смотреть иначе.
Ниже конструктор промтов. Он заставляет того же ассистента искать слабые места: код-ревью с прицелом на защиту, попытка реально пробить систему, отдельный прогон по крайним случаям. Берёшь основной промт, добавляешь нужные блоки, отдаёшь свой код. Чем уже задача, тем точнее ответ. Тот же принцип, что в разработке через тесты: точная постановка экономит часы отладки.
Где ИИ чаще всего оставляет дыры
SQL-инъекции
Запрос собран склейкой строк. Через обычное поле ввода читается вся база.
Доступ к чужому (IDOR)
Данные отдаются по номеру в ссылке без проверки, чьи они. Меняешь цифру, видишь чужое.
XSS
Чужой скрипт попадает на страницу через пользовательский ввод и срабатывает у других людей.
Слабые сессии
Вход и токены сделаны на скорую руку, роли пользователя и администратора путаются.
Команды в обход
Пользовательский ввод уходит в системную команду как есть, без фильтра.
Утечки данных
Чувствительные поля оседают в логах и в ответах сервера, которые никто не вычитывал.
Подделка запроса (CSRF)
Действие выполняется без проверки, что запрос пришёл от самого пользователя.
Гонки
Два запроса в один момент ломают общий счёт или баланс.
Один ассистент, два режима
Отношение к вводу
Доверяет входным данным
Считает любой ввод враждебным
Слово «безопасно»
Скажет, что всё в порядке
Не соглашается, пробует сломать
Глубина
Видит очевидные ошибки
Ищет цепочки и крайние случаи
Что на выходе
Общий совет «валидируйте ввод»
Тип, место, сценарий атаки, исправление
Чей взгляд
Разработчик, который писал
Атакующий снаружи
Это конструктор, не один большой промт. Основной блок идёт всегда. Дополнения добавляешь по ситуации: можно одно, можно несколько сразу. Вставляешь их после основного, перед кодом. Правило простое: один вопрос за раз. Нужна только авторизация, бери блок про авторизацию. Нужен полный разбор взглядом атакующего, добавляй «атакующий угол» и «цепочки». Каждый промт лежит в блоке с кнопкой «Скопировать». Бери целиком.
Основной промт: полный разбор
Отдаёшь ему свой код целиком. Роль задаёшь жёстко: инженер по безопасности с опытом код-ревью и проверки на проникновение. Дальше он ищет слабые места от подстановки в запрос до гонок, и по каждой называет тип, место в коде, сценарий атаки, степень риска и конкретное исправление.
Главное в нём вот что. Промт прямо запрещает соглашаться, что код безопасен. Если явных дыр нет, ассистент обязан сам попробовать сломать код: через крайние случаи, через обходные пути.
Вставляешь промт, под ним свой код, отправляешь. Если разбор нужен на реальном проекте с деньгами и живыми данными, одним промтом не обойтись: тут нужна полноценная работа по ревью и доводке.
Ты инженер по безопасности с опытом код-ревью и проверки на проникновение. Твоя задача: провести глубокий разбор кода на уязвимости и точки утечки данных. ВАЖНО: - Не анализируй сторонние библиотеки и зависимости. Фокус только на логике и реализации этого кода. - Игнорируй стиль, архитектуру и рефакторинг, если это не влияет на безопасность. - Не давай общих советов. Только конкретные уязвимости. Что нужно сделать: 1. Найди ВСЕ возможные уязвимости, включая: - SQL-инъекции - NoSQL-инъекции - Внедрение команд (command injection) - XSS (reflected, stored, DOM) - CSRF - SSRF - Доступ к чужим объектам по идентификатору (IDOR) - Поломанную аутентификацию и авторизацию - Утечки чувствительных данных - Небезопасную работу с файлами - Гонки (если есть асинхронность) - Небезопасную работу с токенами и сессиями - Ошибки валидации входных данных - Логирование чувствительных данных - Любые способы обойти бизнес-логику 2. Для КАЖДОЙ проблемы укажи: - Тип уязвимости - Где именно в коде она находится - Почему это уязвимость (сценарий атаки) - Степень риска (low / medium / high / critical) - Как это можно эксплуатировать (пример атаки) - Как исправить (конкретный код или подход) 3. Отдельно найди: - Места, где уязвимости могут появиться в будущем - Логические ошибки, ведущие к обходу системы - Неочевидные уязвимости, не банальные 4. Если код кажется безопасным, НЕ соглашайся с этим сразу. Попробуй сломать его: - думай как атакующий - ищи обходные пути - проверяй крайние случаи 5. Формат ответа: - Список уязвимостей по приоритету - Затем список потенциальных рисков - Затем краткий итог [ВСТАВЬ КОД СЮДА]
Дополнения: узкие углы
Основной промт ищет широко. Дополнения сужают взгляд до одной точки: посмотреть глазами атакующего, поймать сцепку слабых мест, скормить системе странный ввод.
Добавляешь нужный блок после основного промта, перед кодом. Можно несколько сразу.
Взгляд с другой стороны
Этот блок переключает ассистента в режим человека, у которого есть только публичный доступ к приложению. Он не читает код «как написано». Вместо этого пробует обойти проверки и ищет неочевидные ходы. Хорошо работает для тех частей, что торчат наружу: вход в систему, открытые адреса, на которые приложение отвечает (их называют ручками или endpoint'ами).
Дополнительно: Думай как реальный атакующий, а не как разработчик. - Считай, что у тебя есть только публичный доступ к приложению. - Не доверяй ни одному входному параметру. - Пробуй обойти проверки, а не разбирать их «как есть». - Ищи неочевидные сцепки (например: слабая проверка ввода плюс доступ к чужому идентификатору). Опиши пошагово, как бы ты атаковал эту систему.
Когда одно плюс одно даёт критичное
Одна мелкая дыра сама по себе часто безобидна. Две вместе уже открывают путь к чужим данным или к правам администратора. Этот блок заставляет ассистента искать именно сцепки: как из пары слабых мест собирается серьёзная атака.
Дополнительно: Найди не только отдельные уязвимости, но и возможные цепочки. - Как несколько слабых мест объединяются в одну атаку. - Как из low или medium получить critical. - Как добраться до данных или прав администратора через комбинацию действий. Опиши полный сценарий атаки от начала до результата.
Три точечных блока
Эти три работают в паре с основным, когда нужен прицельный разбор.
Границы доверия. Для кода, который принимает данные снаружи: из запроса, из формы, из чужого сервиса. Находит места, где этим данным верят зря.
Авторизация. Когда у пользователей разные роли и у каждого свои данные. Ищет, где можно дотянуться до чужого или поднять себе права.
Крайние случаи. Для проверки ввода. Кидаешь в неё пустые значения, нули, гигантские числа, не те типы, глубоко вложенные структуры, и смотришь, где треснет.
Дополнительно: Определи границы доверия в системе. - Какие данные приходят извне (ввод пользователя, заголовки, параметры запроса, тело запроса). - Какие данные считаются «доверенными» и почему. - Есть ли места, где недоверенные данные ошибочно приняли за безопасные. Найди нарушения границы доверия.
Дополнительно: Проверь авторизацию максимально строго. - Можно ли получить доступ к чужим данным по идентификатору. - Есть ли проверка владельца ресурса. - Можно ли повысить себе права (из обычного пользователя в администратора). - Есть ли ручки без защиты. Приведи конкретные примеры атак.
Дополнительно: Попробуй сломать систему через крайние случаи. - пустые значения - очень большие значения - неожиданные типы данных - null и undefined - глубоко вложенные структуры Найди, где система ведёт себя неверно или падает.
Где утекают данные и что упускает ассистент
Два следующих блока закрывают отдельные слабые места.
Утечки. Это места, где чувствительные данные уходят не туда: в логи, в подробные сообщения об ошибке, в ответ сервера с лишними полями, в выгрузку, которую никто не вычитывал. Ассистент их часто пропускает, потому что с точки зрения функционала всё «работает правильно».
Скрытые допущения. Когда ассистент генерирует код, он молча считает, что вход всегда правильный, права уже проверены, а данные пришли откуда надо. В реальности это не так, и последний блок ищет именно такие тихие допущения.
Дополнительно: Проверь, где могут утекать чувствительные данные. - через логи - через сообщения об ошибках - через ответы сервера - через связи в данных (когда по одному объекту вытягивается лишнее) - через сериализацию объектов Укажи конкретные места и примеры.
Дополнительно: Считай, что код написан неопытным разработчиком или сгенерирован ИИ. - Ищи скрытые допущения. - Ищи места, где «кажется безопасно», но это не так. - Проверяй всё, даже очевидное. Сосредоточься на неочевидных уязвимостях.
Для большинства проектов хватает основного промта плюс трёх дополнений: «атакующий угол», «цепочки», «утечки данных». Они перекрывают самые частые классы дыр в обычном вайбкоде: слабая проверка прав, сцепленные атаки, данные в логах. Добавляешь их один за другим после основного промта, перед кодом.
Если нужен готовый отчёт
Бывает, разбор надо показать команде или заказчику в собранном виде. Тогда добавь этот блок последним: он задаёт форму. Короткое резюме, список по степени риска, сценарии атак, рекомендации.
А если по находкам нужен живой разбор, что чинить в первую очередь и как, это уже консультация по архитектуре.
Дополнительно: Оформи ответ как отчёт по безопасности. - Короткое резюме (executive summary) - Critical - High - Medium - Low - Сценарии атак - Рекомендации Без воды, только по делу.
Частые вопросы
Нашёл дыры и нужен разбор?
Если аудит выдал список уязвимостей и нужна помощь приоритизировать или закрыть их в коде, это задача для разбора один на один. За час проходим находки, решаем, что критично, что терпит, и как именно чинить.
Обсудить проект