ГК Softline: зеленый отчет сканера уязвимостей маскирует реальные риски
изображение: grok
Руководители ИБ-служб часто полагают, что регулярное автоматическое сканирование инфраструктуры гарантирует обнаружение и закрытие всех уязвимостей. Это мнение формирует ложное чувство защищенности. Рассказываем, почему автоматизация не поможет там, где нужно понимать логику приложения.
Сканеры уязвимостей работают по сигнатурам и шаблонам и ищут известные паттерны уязвимостей. Такой инструмент видит факт аутентификации: наличие логина, переданного токена или активной сессии. Например, в интернет-магазине покупатель формирует заказ и в момент оплаты сайт отправляет запрос к API с параметром ‘order_id=345’. Сервер видит этот номер, подгружает сумму, адрес доставки, список товаров. В результате платеж успешно проходит. Сканер в это время проверяет веб-формы на наличие классических уязвимостей: подставляет кавычки, угловые скобки, длинные строки и смотрит на коды ответов. Если ничего не вызывает подозрений, то никаких сигналов ИБ-специалисты не получат.
Однако если мошенники подставят вместо своего номера заказа чужой, а сервер не убедится, что заказ действительно принадлежит этому пользователю, произойдет утечка чужих данных. Меняя идентификаторы один за другим, можно выгрузить всю базу заказов.
Опыт ИБ-проектов Softline показывает, что чрезмерное доверие к автоматизированным отчетам создает иллюзию контроля. Тогда как реальная защита требует понимания логики приложения, которую невозможно полноценно проверить только шаблонными запросами. Яркий пример такой слепой зоны: уязвимость IDOR (Insecure Direct Object Reference). Это проблема в системе контроля доступа, когда веб-приложение или API раскрывает внутренние идентификаторы и пользователь может получить чужие данные, изменив параметры. В мире API эта проблема известна как BOLA (Broken Object Level Authorization).
Если компания не замечает эти риски, то могут произойти инциденты, которые обернутся утечкой конфиденциальных данных и финансовым ущербом. Так как злоумышленники могут просматривать платежные данные клиентов, менять или удалять их заказы, а также захватывать учетные записи.
Чтобы минимизировать эти риски, мы в Softline рекомендуем компаниям дополнять автоматизированную защиту ручным тестированием на проникновение (пентестом). Специалисты изучат поверхность атаки, будут искать точки входа и вручную генерировать поддельные запросы, подставляя параметры и манипулируя логикой приложения.
Кроме того, необходимо внедрять процессы проверки бизнес-логики на этапах разработки приложения. Моделирование угроз поможет обнаружить отсутствие проверок авторизации до того, как код попадет в продуктовую среду. Следует изучить архитектуру интеграций и определить границы доверия, а также выявить элементы, обрабатывающие данные, и оценить существующие механизмы безопасности. Затем применяется моделирование угроз по методике STRIDE, в охват которой входят такие действия, как подмена, несанкционированное изменение, отказ от действий, раскрытие информации, отказ в обслуживании, повышение привилегий.
Директорам по информационной безопасности и топ-менеджерам нужно учитывать, что сканер уязвимостей не заменяет оценку рисков бизнес-логики и не гарантирует защиту активов. Управленческое решение заключается в пересмотре архитектуры контроля доступов и внедрении принципов безопасной разработки.
