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