Claude Code для безопасности сайта: как ИИ-агент расследовал атаку и нашёл скрытую дыру
Утром во время прямого эфира на форму отзывов одного из онлайн-курсов начали сыпаться десятки «отзывов»: имя автора — бессмысленный набор букв, текст — «555». Сотни штук. Владелец сайта предположил DDoS-атаку, потом — что у атакующих есть ИИ, обходящий капчу. Обе версии оказались неверными. Правду установил не человек, а ИИ-агент Claude Code, которому сказали по-человечески: «Кажется, нас атакуют, разберись». Агент провёл расследование как инженер по безопасности: поставил диагноз, проверил гипотезы двумя независимыми способами, нашёл настоящую проблему — капчу, которая физически не существовала, хотя владелец почти год считал её включённой, — и закрыл уязвимость правильным инструментом.
Источник: t.me
Эта история важна не как курьёз, а как рабочий метод. Если у вас есть сайт с формами — заявки, отзывы, заказы, — у вас почти наверняка есть настройки защиты, которые «включены в админке», но не работают. Ниже — что именно произошло, какие проверки сделал агент и как повторить этот подход у себя, даже без ИИ-агента.
Что именно произошло: от паники к диагнозу за один сеанс
Сценарий знаком любому владельцу сайта: в админке внезапно появляются сотни мусорных записей. Первая реакция — «нас атакуют», вторая — «надо срочно что-то включить». Владелец включил капчу, поток не остановился, и появилась вторая паническая гипотеза: у атакующих есть ИИ, который решает капчи. В 2026 году это звучит правдоподобно — и именно поэтому опасно: красивая гипотеза легко подменяет проверку.
Вместо того чтобы лезть в логи вручную, владелец поручил расследование Claude Code — ИИ-агенту, который управляет его сайтом. Дальше агент действовал последовательно:
- Проверил нагрузку сервера. Она не изменилась вообще. Значит, это не DDoS: сервер атаку даже «не почувствовал». Первая гипотеза отпала за минуту.
- Посмотрел содержимое мусорных записей. Там оказались классические SQL-инъекции — команды, которые заставляют базу данных «уснуть» на 15 секунд, если защита дырявая. Это работа автоматического сканера уязвимостей sqlmap (стандартный открытый инструмент), который методично прощупывал форму: около 490 попыток за час.
- Проверил, сработала ли инъекция, двумя независимыми способами. Первый — замер интервалов между сотнями запросов: если бы база реально «засыпала» на 15 секунд, это было бы видно в таймингах; медиана оказалась 2 секунды. Второй — чтение кода формы: весь пользовательский ввод обрабатывался безопасно, инъекция была структурно невозможна. Вердикт: дыры нет, сканер ушёл ни с чем.
- Проверил капчу так, как её видит бот. Вместо веры в «ИИ, обходящий капчи» агент запросил страницу и посмотрел, что реально отдаёт сервер. Поля капчи в ответе не было. Вообще. Выяснилось: общий рубильник «включить капчу» в плагине ничего не включает — у каждой формы своя настройка, и она была пуста. Больше того, сам модуль капчи даже не был установлен. Никто ничего не обходил: дверь просто никогда не была заперта.
- Закрыл проблему правильным инструментом. Не капчей, а доступом: страница с формой теперь видна только авторизованному студенту. Анонимный сканер больше не видит форму — ему физически нечего атаковать.
- Вычистил последствия. 489 мусорных записей удалены из очереди.
Почему это меняет экономику реагирования на инциденты
Разберём, что здесь важно для бизнеса, а не только для технаря. Такое расследование у штатного специалиста по безопасности или привлечённого подрядчика — это часы работы и счёт за консультацию. У владельца без технического бэкграунда — это вообще тупик: он не знает, куда смотреть, и начинает «лечить» первую попавшуюся гипотезу.
Здесь же весь цикл — диагноз, двойная проверка, поиск настоящей причины, исправление, зачистка — уложился в один диалог с агентом. Но главная выгода не в скорости, а в качестве решения. Человек в панике почти наверняка остановился бы на шаге «включил капчу — не помогло — купил более дорогую защиту от ботов». И потратил бы деньги на решение несуществующей проблемы, потому что настоящая проблема была в другом: защита, которую он считал работающей, не существовала физически.
| Что меняется | Почему важно бизнесу | Что проверить |
|---|---|---|
| Диагноз ставится по данным, а не по панике | Не тратите деньги на защиту от несуществующей угрозы | Нагрузку сервера и содержимое мусорных запросов до любых действий |
| Гипотеза проверяется двумя независимыми способами | Меньше риск «вылечить» не то и оставить дыру | Тайминги запросов + код формы, а не одно наблюдение |
| «Включено в админке» проверяется снаружи | Годами висящие мёртвые настройки — типичный скрытый риск | Что реально отдаёт сервер анонимному посетителю |
| Закрытие доступа вместо капчи | Капча даёт боту шанс попытаться; закрытая дверь — нет | Какие формы вообще должны быть видны анонимам |
Как превратить это в повторяемый рабочий процесс
Из этого кейса можно собрать метод, который работает и с ИИ-агентом, и без него. Суть — дисциплина расследования: сначала факты, потом гипотезы, потом лечение.
Шаг 1. Зафиксируйте симптом, не действуя. Сколько записей, за какой период, что внутри. В нашем случае содержимое записей сразу указало на sqlmap — это изменило всё расследование.
Шаг 2. Проверьте самую страшную гипотезу самым дешёвым способом. DDoS опровергается одним взглядом на график нагрузки. Не начинайте с дорогих мер против угрозы, которую можно опровергнуть за минуту.
Шаг 3. Проверяйте успех атаки, а не её наличие. Сканер уязвимостей стреляет по тысячам сайтов автоматически. Вопрос не «атаковали ли нас» (да), а «сработало ли хоть что-то» (здесь — нет, и это доказано двумя способами). От ответа зависит, нужна ли эвакуация или достаточно профилактики.
Шаг 4. Проверяйте защиту с позиции атакующего. Запросите страницу так, как её видит анонимный бот, и посмотрите на фактический ответ сервера. Это единственная честная проверка. Галочка в админке — это заявление о намерении, а не работающий механизм.
Шаг 5. Выбирайте средство под угрозу. Если атакуют анонимные боты, а форма нужна только зарегистрированным пользователям, — закрытие доступа сильнее любой капчи: бот не получает даже шанса попытаться.
Шаг 6. Зачистите последствия и зафиксируйте вывод. Удалите мусор, запишите, что было проверено и как, — это сэкономит часы при следующем инциденте.
Где ограничения и риски этого подхода
Это один практический кейс, а не гарантия. Стоит держать в уме несколько оговорок.
Во-первых, агент смог расследовать инцидент, потому что у него был доступ к серверу, логам и коду сайта — он уже управлял этим сайтом. ИИ-агент «с улицы», без доступа к вашей инфраструктуре, такое расследование не проведёт. Это означает и обратный риск: вы даёте автоматизированной системе широкие права, и вопрос контроля за её действиями становится вашей новой обязанностью.
Во-вторых, вывод «дыры нет» верен для конкретной формы и конкретного кода. Это не аудит всего сайта. Сканер прощупывал одну форму — состояние остальных этот кейс не покрывает.
В-третьих, самое неприятное открытие кейса — не про ИИ, а про людей. Капча «была включена» почти год и ни разу никого не остановила, потому что физически не существовала. Сколько таких мёртвых настроек на типичном корпоративном сайте — резервное копирование, которое «настроено», уведомления, которые «приходят», SSL, который «продлевается автоматически», — никто не знает, пока не проверит снаружи. ИИ-агент здесь лишь ускорил проверку, которую владелец мог сделать сам, но не делал.
Наконец, детали истории известны со слов её участника. Метод при этом проверяем независимо: каждый шаг можно повторить на собственном сайте и убедиться самому.
Что сделать на этой неделе
Не ждите атаки, чтобы узнать, какие из ваших защит мертвы. Практический чек-лист для владельца или руководителя — без погружения в код:
- Запросите каждую публичную форму сайта как анонимный посетитель (режим инкогнито, без входа в аккаунт) и проверьте, что защита реально присутствует на странице, а не только в админке.
- Составьте список форм, которые вообще не нужны анонимам — отзывы от студентов, внутренние заявки — и закройте их по доступу вместо капчи.
- Проверьте логи за последний месяц на всплески мусорных отправок — возможно, сканеры уже приходили, и вы узнаете, что именно они искали.
- Проверьте тайминги ответов сервера при подозрительной активности: аномальные паузы могут означать, что инъекция частично срабатывает.
- Заведите короткий протокол инцидента: симптом → проверка нагрузки → анализ содержимого → проверка успеха атаки → исправление → зачистка. Повесьте его там, где его найдёт тот, кто первым увидит проблему.
- Если используете ИИ-агента с доступом к сайту, определите границы его полномочий до инцидента, а не во время.
Главный вывод кейса прост: ценность ИИ-агента здесь не в том, что он «умный», а в том, что он дисциплинированный — не поверил ни в DDoS, ни в «ИИ, обходящий капчи», а пошёл смотреть факты. Эту дисциплину можно перенять независимо от того, какие инструменты вы используете. А мёртвая капча, год висевшая в состоянии «включено», — хороший повод проверить, какие ещё защиты на вашем сайте существуют только в админке.
Источники
Темы журнала
Что почитать дальше
- Kimi вместо Claude: проверка скорости, качества и стоимости для бизнеса
- Claude Opus 5 для бизнеса: цена API, риски доступа и проверка ROI
- Claude Code Starter v6.3.0: оркестрация AI-агентов без хаоса
- Vibe Coding на Claude Code: ROI и риски курса для профи 40+
- Бесплатный курс вайб-кодинга на Claude Code для не-программистов 40+
