Спасибо за интересный разбор. Особенно близок подход, при котором ИБ участвует в проектировании архитектуры, а не появляется только на этапе согласования готового решения.
В своей практике эксплуатации инфраструктуры для государственных организаций регулярно сталкиваюсь с другой стороной этой задачи — взаимодействием между SOC и эксплуатацией.
Например, сканер обнаруживает потенциальную уязвимость, но установленный пакет уже содержит исправление без изменения основной версии либо риск закрыт компенсирующими мерами. В результате приходится повторно обосновывать фактическое состояние защиты.
На мой взгляд, здесь важна не только автоматизация выявления уязвимостей, но и сохранение контекста принятых решений: какие меры реализованы, чем подтверждена их эффективность и когда требуется повторная проверка.
Интересно, как у вас организован учёт таких исключений и компенсирующих мер? Может ли эксплуатация самостоятельно инициировать пересмотр статуса находки на основании технических доказательств?
Интересный эксперимент с локальной LLM и DOM-агентом. Особенно понравилась идея использовать семантические маркеры вместо нестабильных CSS-классов.
Но с точки зрения антибот-защиты я бы осторожнее относился к выводу, что запуск обычного Edge в headed-режиме делает автоматизацию неотличимой от человека.
Сейчас исследую обнаружение автоматизированных клиентов по TLS/JA4 и HTTP/2 fingerprints. Видимость окна браузера — лишь один из множества признаков, а сетевые отпечатки и последовательности запросов позволяют анализировать клиента независимо от этого.
К тому же полученный на шестом обращении HTTP 429 показывает, что по крайней мере часть защитных механизмов продолжала работать.
Было бы интересно узнать, удалось ли сравнить TLS/HTTP2-отпечатки автоматизированного Edge и обычной пользовательской сессии, а также выяснить, на каком именно уровне срабатывала защита.
Хорошая статья, особенно понравился акцент на покрытии поверхности атаки и воспроизводимости находок.
Добавлю наблюдение со стороны эксплуатации WAF. При регулярном DAST-сканировании production возникает интересная проблема: защитные механизмы могут заблокировать сканер раньше, чем он доберётся до потенциально уязвимого функционала.
При этом простое добавление IP сканера в полный allowlist тоже не всегда подходит: мы начинаем проверять приложение в условиях, отличающихся от тех, в которых работает обычный клиент.
На практике приходится отдельно продумывать режим сканирования, исключения, ограничения нагрузки и интерпретацию результатов.
Интересно, как вы рекомендуете организовывать совместную работу DAST и WAF в production? Есть ли у вас подход к разделению проверки самого приложения и проверки эффективности защитного периметра?
Информация
В рейтинге
Не участвует
Откуда
Краснодар, Краснодарский край, Россия
Дата рождения
Зарегистрирован
Активность
Специализация
Фулстек разработчик, Архитектор программного обеспечения
Спасибо за интересный разбор. Особенно близок подход, при котором ИБ участвует в проектировании архитектуры, а не появляется только на этапе согласования готового решения.
В своей практике эксплуатации инфраструктуры для государственных организаций регулярно сталкиваюсь с другой стороной этой задачи — взаимодействием между SOC и эксплуатацией.
Например, сканер обнаруживает потенциальную уязвимость, но установленный пакет уже содержит исправление без изменения основной версии либо риск закрыт компенсирующими мерами. В результате приходится повторно обосновывать фактическое состояние защиты.
На мой взгляд, здесь важна не только автоматизация выявления уязвимостей, но и сохранение контекста принятых решений: какие меры реализованы, чем подтверждена их эффективность и когда требуется повторная проверка.
Интересно, как у вас организован учёт таких исключений и компенсирующих мер? Может ли эксплуатация самостоятельно инициировать пересмотр статуса находки на основании технических доказательств?
Интересный эксперимент с локальной LLM и DOM-агентом. Особенно понравилась идея использовать семантические маркеры вместо нестабильных CSS-классов.
Но с точки зрения антибот-защиты я бы осторожнее относился к выводу, что запуск обычного Edge в headed-режиме делает автоматизацию неотличимой от человека.
Сейчас исследую обнаружение автоматизированных клиентов по TLS/JA4 и HTTP/2 fingerprints. Видимость окна браузера — лишь один из множества признаков, а сетевые отпечатки и последовательности запросов позволяют анализировать клиента независимо от этого.
К тому же полученный на шестом обращении HTTP 429 показывает, что по крайней мере часть защитных механизмов продолжала работать.
Было бы интересно узнать, удалось ли сравнить TLS/HTTP2-отпечатки автоматизированного Edge и обычной пользовательской сессии, а также выяснить, на каком именно уровне срабатывала защита.
Хорошая статья, особенно понравился акцент на покрытии поверхности атаки и воспроизводимости находок.
Добавлю наблюдение со стороны эксплуатации WAF. При регулярном DAST-сканировании production возникает интересная проблема: защитные механизмы могут заблокировать сканер раньше, чем он доберётся до потенциально уязвимого функционала.
При этом простое добавление IP сканера в полный allowlist тоже не всегда подходит: мы начинаем проверять приложение в условиях, отличающихся от тех, в которых работает обычный клиент.
На практике приходится отдельно продумывать режим сканирования, исключения, ограничения нагрузки и интерпретацию результатов.
Интересно, как вы рекомендуете организовывать совместную работу DAST и WAF в production? Есть ли у вас подход к разделению проверки самого приложения и проверки эффективности защитного периметра?