Купив сканер уязвимостей, очень хочешь доверять ему. Если он показывает, что всё хорошо, то, наверное, так оно и есть. Однако у каждого инструмента — свой набор задач, и есть те области, которые сканер не видит. Рассказываем, как чрезмерное доверие к отчёту сканера может вылиться в реальные убытки.
- 1. Введение
- 2. Как выглядит уязвимость, которую сканер не замечает
- 3. Почему сканер проходит мимо IDOR
- 4. Чем это оборачивается для бизнеса
- 5. Не вместо, а вместе
- 6. Почему CISO не должен верить «зелёному» отчёту
- 7. Выводы
Введение
Многие руководители по ИБ уверены: если регулярно прогонять инфраструктуру через сканер, то все уязвимости будут найдены и закрыты. Это миф «сканер всё покажет» — удобное заблуждение, которое живёт в десятках компаний, от финтеха до промышленности. На примере одной из самых коварных проблем контроля доступа — IDOR (нарушение логики разграничения доступа) — разбираемся, почему автоматизация бессильна там, где нужно понимать логику приложения, и чем реальная защита отличается от имитации.
Как выглядит уязвимость, которую сканер не замечает
Представим интернет-магазин. Покупатель формирует заказ, переходит к оплате, и в этот момент сайт отправляет запрос к API с параметром 'order_id=345'. Сервер видит этот номер, подгружает сумму, адрес доставки, список товаров — и платёж успешно проходит. Сканер безопасности, который настроен на автоматическое сканирование, в это время проверяет веб-формы на наличие классических уязвимостей: подставляет кавычки, угловые скобки, длинные строки и смотрит на коды ответов. Если ответы выглядят штатно, компания получает «зелёный» отчёт, показывающий, что уязвимости отсутствуют.
Но если злоумышленник подставит вместо своего номера заказа чужой — например, 'order_id=355', — а сервер не выполнит проверку, не убедится, что заказ действительно принадлежит этому пользователю, произойдёт утечка чужих данных. Меняя идентификаторы один за другим, можно выгрузить всю базу заказов, попасть в чужие личные кабинеты, а если API, так сказать, «посерьёзнее», то и получить доступ к документам, платёжным историям и другим чувствительным сведениям.
Это и есть IDOR (Insecure Direct Object Reference) — серьёзная проблема в системе контроля доступа, когда веб-приложение или API раскрывает внутренние идентификаторы и пользователь может получить чужие данные, просто поменяв параметр. Тот же механизм в мире API называется BOLA (Broken Object Level Authorization) и возглавляет рейтинг OWASP API Security Top 10. Такая уязвимость возникает, когда сервер подтверждает личность пользователя (аутентифицирует), но не проверяет, есть ли у того право запрашивать, изменять или удалять конкретный объект — например, чужую учётную запись или, как в нашем примере, номер заказа.
Почему сканер проходит мимо IDOR
Сканер уязвимостей отлично справляется с проверкой аутентификации — он видит, что пользователь залогинился, токен передан, сессия активна. Но авторизация на уровне конкретного объекта для него — тёмный лес. Разработчики часто реализуют вход по логину и паролю или через JWT, и сервер знает, кто отправил запрос. Однако знать, кто ты, и знать, можно ли тебе читать или изменять заказ с номером 355, — это две разные вещи. Вторая проверка (авторизация) часто забывается, и именно на этом строится атака.
Сканеры работают по сигнатурам и шаблонам, не проверяя логику приложения. Они ищут известные паттерны уязвимостей. Например, неэкранированные символы вроде <script> для межсайтового скриптинга (XSS), изменение структуры SQL-запроса с помощью полезной нагрузки ' OR '1'='1' — для инъекций, типовые пути к файлам вроде '../../etc/passwd', нестандартные HTTP-коды, задержки ответов. Они модифицируют параметры — добавляют кавычки, теги, спецсимволы, длинные строки — и сравнивают ответы с эталонными. Если структура ответа изменилась, они сигнализируют о проблеме. Но они не моделируют поведение злоумышленника, который перебирает соседние идентификаторы в расчёте на то, что система не проверит права.
Есть и технический нюанс: сервер при эксплуатации IDOR чаще всего возвращает обычный код 200/OK, а не ошибку 403/Forbidden (доступ запрещён) или 500/Internal Server Error (сервер не может обработать полученный запрос). Он не падает, не выдаёт трассировку стека, не тормозит — он просто отдаёт данные. Запрос на свой заказ возвращает код 200, на чужой — тоже 200. Для сканера оба ответа одинаково валидны, ведь у него нет критерия «чьи эти данные». Он не может показать, что в одном случае показана личная информация, а в другом — чужая.
Ещё одна существенная деталь: чтобы обнаружить IDOR, нужно действовать минимум от двух учётных записей. Пользователь А создаёт объект (скажем, заказ с номером 345), пользователь Б пытается получить к нему доступ через свою сессию. Если доступ получен, значит, уязвимость есть. Но подавляющее большинство сканеров работают в пределах одного сеанса, одного пользователя. Они не умеют держать два токена, отслеживать объекты, созданные разными учётками, и сравнивать результаты. Это уже территория специализированных расширений вроде Autorize для Burp Suite или интеграционных тестов, но никак не стандартного сканера.
Также сканеры не понимают контекст идентификаторов. Для него 'order_id=345' — просто число. Он может подставить '0', '-1', '999999', '345' или ' OR '1'='1', но он не знает, что «345» — это «мой заказ», а «355» — «чужой». Ему неоткуда узнать, какие идентификаторы относятся к текущему пользователю, какие — тестовые, а какие — реальные. Для такого анализа нужна семантическая модель данных, понимание схемы и диапазонов, а у автоматического инструмента этого нет. Фактически, у сканера отсутствует эталон «запрещённого ответа» — он не знает, как должен выглядеть отказ в доступе, поэтому два успешных ответа он воспринимает как одинаково корректные.
Всё это не баг конкретной модели, а системное ограничение автоматического анализа защищённости. Сканер делает своё дело, но задача «найти IDOR» просто не входит в его базовые возможности по определению.
Чем это оборачивается для бизнеса
Когда IDOR или BOLA остаются незамеченными, последствия становятся реальными и очень болезненными. Злоумышленник может просматривать платёжные данные других клиентов, редактировать или удалять их заказы, захватывать учётные записи и даже провоцировать отказ в обслуживании, удаляя критически важные ресурсы. Это не гипотетическая угроза — такие инциденты регулярно случаются с компаниями, которые полагались только на результаты работы автоматических сканеров.
Если коротко, то алгоритм следующий: нарушается конфиденциальность — данные утекают, нарушается целостность — чужие записи подделываются или уничтожаются, а репутационные и финансовые потери могут быть колоссальными. И всё это может произойти в компании, где сканер исправно работает, а руководитель ИБ спокойно смотрит на зелёные индикаторы.
Не вместо, а вместе
Итак, чтобы действительно закрыть такие уязвимости, одних сканеров недостаточно. Они не анализируют логику приложения и контекст прав доступа — а именно это и эксплуатируют хакеры. Для выявления IDOR требуется ручное тестирование на проникновение (пентест), причём с использованием двух и более учётных записей. Пентестер не просто прогоняет скрипты: он изучает поверхность атаки, ищет точки входа, вручную генерирует поддельные запросы, подставляет параметры и манипулирует логикой приложения. Результатом становится отчёт, где есть не только описание найденных проблем, но и артефакты, оценка рисков и конкретные рекомендации по исправлению.
При этом не стоит противопоставлять ручной поиск уязвимостей (тот же пентест) автоматическому — они работают в разных областях и дополняют друг друга. Сканеры отлично ловят типовые уязвимости по сигнатурам, а пентест — логические и контекстные дефекты вроде IDOR. В идеале они должны идти рука об руку.
Но ещё более надёжный путь — проактивный. Анализ архитектуры и моделирование угроз на ранних стадиях разработки приложения позволяют выявить отсутствие проверок авторизации до того, как код попадёт в продуктовую среду. Для этого изучаются архитектура интеграций (схемы взаимодействия, спецификации API, структуры данных и информационные потоки), определяются границы доверия (клиент, DMZ, внутренняя сеть, база данных, сторонние сервисы), выявляются элементы, обрабатывающие данные, и оцениваются существующие механизмы безопасности.
Затем применяется моделирование угроз по методике STRIDE, в охват которой входят такие действия, как подмена, несанкционированное изменение, отказ от действий, раскрытие информации, отказ в обслуживании, повышение привилегий. Для каждой границы доверия и каждого потока данных строится дерево возможных атак, выполняется оценка рисков и генерируются требования к контрмерам. На выходе получаем диаграммы потоков данных, таблицы угроз, требования к безопасной разработке, список архитектурных решений для пересмотра и сценарии для дальнейшего тестирования.
Почему CISO не должен верить «зелёному» отчёту
Сканер в компании, вероятно, работает исправно. Но вопрос к CISO и руководителям разработки должен звучать иначе: кто и когда серьёзно думал о том, как взломать ваше приложение? Сканер ищет только то, что уже заложено в его базу сигнатур. Пентестер же пытается мыслить как атакующий — он ищет нестандартные ходы и задаёт вопросы, которых нет ни в одном скрипте.
Выводы
Миф «сканер всё покажет» опасен не потому, что он полностью ложный. Сканеры полезны, и без них в современном ИБ не обойтись. Проблема в другом — в иллюзии, которую они создают. Когда CISO видит «зелёный» отчёт, он успокаивается. А злоумышленник в это время спокойно меняет цифры в адресной строке, потому что разработчики забыли добавить одну проверку, а автоматическая проверка её не требует.
Граница между формальной проверкой и реальной безопасностью проходит ровно там, где заканчиваются возможности скриптов. Дальше нужен человек, который видит приложение не как набор портов и заголовков, а как сложную систему с контекстом, правами, логикой и неочевидными связями.
