A05: Мисконфигурация безопасности
Security Misconfiguration (A05) — это не один баг в коде, а целый класс ситуаций, когда система написана правильно, но настроена небезопасно. Сюда попадает всё, что относится к конфигурации: оставленные дефолтные значения, включённые лишние функции, неудалённые тестовые компоненты, забытые открытые порты и сервисы.
Аналогия: вы купили хороший дверной замок, но не сменили заводской код «0000», оставили запасной ключ под ковриком и не закрыли окно на первом этаже. Сам замок надёжен — небезопасна настройка всей квартиры.
Первопричина
Глубинная причина A05 — отсутствие управляемого процесса hardening (укрепления) и принципа «безопасно по умолчанию». Системы из коробки настроены на удобство запуска, а не на безопасность: включён максимум функций, открыт максимум интерфейсов, заведены демо-учётки. Без сознательного ужесточения это удобство превращается в поверхность атаки. Усугубляет проблему «configuration drift» — со временем накапливаются ручные правки, временные исключения и забытые отладочные флаги, которые никто не отслеживает.
Типичные проявления
- Дефолтные учётные данные.
admin/admin,rootбез пароля, заводские пароли роутеров и админок (Tomcat, Jenkins, СУБД, IoT). Атакующему достаточно знать модель устройства, чтобы войти. - Включённые отладочные режимы наружу.
DEBUG=Trueв продакшене, подробные стек-трейсы и трассировки в ответах ошибок. Они раскрывают пути файловой системы, версии библиотек, фрагменты SQL-запросов, внутренние IP — готовую карту для атакующего. - Лишние открытые сервисы и порты. Наружу «торчат» панели управления, БД (3306/5432), Redis/Memcached без пароля, тестовые эндпоинты
/actuator,/debug,/phpinfo.php. - Отсутствие security-заголовков HTTP (о них во второй секции).
- Открытые облачные хранилища. Публичные S3-бакеты, GCS- и Azure Blob-контейнеры с доступом «для всех» — классическая причина массовых утечек: бэкапы, ПДн, ключи лежат по угадываемому URL.
Типичная ошибка: считать, что «раз внутри сети — значит безопасно», и оставлять админки и БД без аутентификации, полагаясь только на сетевой периметр. Любая SSRF, скомпрометированный сервис или ошибка фаервола мгновенно превращают «внутренний» сервис в публичный.
Мини-итог: A05 — это небезопасная настройка корректно написанной системы; первопричина в отсутствии процесса hardening и принципа «безопасно по умолчанию». Лечится не патчем, а дисциплиной: минимизация функций, смена всех дефолтов, скрытие отладочной информации и регулярный аудит конфигурации.
Меры против A05: бьём в первопричину
Поскольку первопричина A05 — отсутствие управляемого ужесточения, защита строится не на единичных фиксах, а на повторяемом процессе hardening.
Принцип минимизации (least functionality)
Всё, что не нужно для работы сервиса, должно быть выключено и удалено: неиспользуемые модули, демо-приложения, тестовые эндпоинты, лишние HTTP-методы (TRACE, PUT, если не нужны). Каждый отключённый компонент — это поверхность атаки, которой больше нет. Открытые порты сводятся к строго необходимым, всё остальное закрывается фаерволом и сегментацией.
Смена дефолтов и сокрытие технической информации
Первым действием при развёртывании любого компонента меняются все заводские учётные данные и секреты. В продакшене отключаются отладка и подробные ошибки: пользователь видит нейтральное «Произошла ошибка», а полная диагностика уходит во внутренние логи (см. A09). Баннеры версий и заголовки типа Server: nginx/1.x.x минимизируются, чтобы не подсказывать атакующему, какие CVE искать.
Security-заголовки HTTP
Заголовки ответа — дешёвый слой защиты, который многие забывают включить:
Content-Security-Policy(CSP) — ограничивает, откуда грузятся скрипты/стили; сильнейшая мера против XSS (A03).Strict-Transport-Security(HSTS) — принуждает браузер всегда ходить по HTTPS, защищает от downgrade и перехвата.X-Content-Type-Options: nosniff— запрещает браузеру «угадывать» тип контента (защита от MIME-sniffing атак).X-Frame-Options/frame-ancestorsв CSP — защита от clickjacking (встраивание сайта в чужой iframe).Referrer-Policy,Permissions-Policy— ограничивают утечку реферера и доступ к API браузера.
Облачные хранилища
Бакеты по умолчанию должны быть приватными; публичный доступ включается только осознанно и точечно. Включаются блокировки публичного доступа на уровне аккаунта, шифрование at-rest и логирование обращений.
Процесс, а не разовое действие
Hardening закрепляется в базовых конфигурациях (baseline) и проверяется автоматически: чек-листы CIS Benchmarks, сканеры конфигураций, Infrastructure as Code с ревью. Конфигурация должна быть воспроизводимой и одинаковой на всех стендах — это убивает configuration drift.
Типичная ошибка: настроить безопасность вручную на одном сервере и забыть про остальные; уже завтра новый инстанс развернётся со старыми дефолтами. Безопасная конфигурация должна быть кодом, а не подвигом одного инженера.
Мини-итог: против A05 работают минимизация (выключить лишнее), смена всех дефолтов, скрытие отладочной информации, набор security-заголовков и приватные бакеты — и всё это закреплённое в воспроизводимом, автоматически проверяемом baseline, а не сделанное руками один раз.
A06: Уязвимые и устаревшие компоненты
Современное приложение на 70–90% состоит из чужого кода: фреймворки, библиотеки, образы контейнеров, плагины. Vulnerable and Outdated Components (A06) — это риск использования компонентов с известными уязвимостями.
Аналогия: вы построили дом из готовых блоков. Если завод-производитель объявил, что партия блоков бракованная, — ваш дом в опасности, даже если вы всё собрали идеально. Проблема не в вашей сборке, а в чужом блоке внутри стены.
Первопричина
Главная причина A06 — отсутствие учёта и управления зависимостями. Команда часто не знает полного списка того, что реально установлено (включая транзитивные зависимости — библиотеки, которые тянут другие библиотеки), не отслеживает выход CVE и не обновляется вовремя. Уязвимость публичная, патч есть, но до конкретной системы он не доходит месяцами.
Почему это опасно: эксплуатация по готовому сценарию
С A06 атакующему не нужно искать новый баг — он берёт публичный эксплойт к известной CVE и массово сканирует Интернет в поисках уязвимой версии. Между публикацией уязвимости и началом массовой эксплуатации часто проходят часы.
Кейс: Log4Shell — CVE-2021-44228
В декабре 2021 года в библиотеке логирования Apache Log4j 2 (Java) была раскрыта критическая уязвимость Log4Shell, CVE-2021-44228 (CVSS 10.0). Суть: Log4j поддерживал подстановку выражений вида ${jndi:ldap://...} прямо в логируемых строках. Если атакующий передавал такую строку в любое поле, которое приложение логировало (например, в заголовок User-Agent), Log4j через JNDI ходил по указанному адресу и загружал удалённый Java-класс — это давало удалённое выполнение кода (RCE) без аутентификации.
Опасность была колоссальной именно из-за A06-природы: Log4j встроен в тысячи продуктов транзитивно. Многие команды даже не знали, что используют Log4j — он был зависимостью зависимости. Нельзя пропатчить то, о существовании чего не подозреваешь. Это и есть наглядная иллюстрация первопричины A06: без учёта зависимостей вы не можете ни оценить риск, ни закрыть его.
Защита: SCA и управление обновлениями
- SCA (Software Composition Analysis) — инструменты (OWASP Dependency-Check, Snyk, Trivy, Dependabot), которые автоматически сверяют список зависимостей с базами CVE и предупреждают об уязвимых версиях.
- SBOM (Software Bill of Materials) — формализованная «опись состава» ПО: что и какой версии внутри. Без неё на вопрос «у нас есть уязвимый Log4j?» нельзя ответить за минуты.
- Регулярные обновления и патч-менеджмент — процесс, а не аврал: следить за бюллетенями, тестировать и накатывать обновления; удалять неиспользуемые зависимости.
Типичная ошибка: «работает — не трогай»: годами не обновлять библиотеки, боясь сломать совместимость. В итоге накапливается ворох известных CVE, и система становится грудой готовых эксплойтов.
Мини-итог: A06 — риск чужого кода с известными уязвимостями; первопричина — отсутствие учёта и управления зависимостями. Log4Shell (CVE-2021-44228) показал, как транзитивная зависимость даёт RCE по публичному эксплойту. Защита — SCA, SBOM и дисциплинированный патч-менеджмент.
# A05: отладка и стек-трейсы наружу — раскрывают версии и пути curl -i https://websec-portal-01/this-page-does-not-exist # Признак мисконфигурации в ответе: полный stack trace, # заголовок 'Server: ...', путь '/var/www/app/...' # A05: проверка security-заголовков (что ОТСУТСТВУЕТ — то и проблема) curl -sI https://websec-portal-01/ | grep -iE 'content-security-policy|strict-transport-security|x-content-type-options|x-frame-options' # Пустой вывод = заголовки не выставлены # A05: дефолтные/тестовые эндпоинты, забытые после отладки curl -s https://websec-portal-01/actuator/env curl -s https://websec-portal-01/phpinfo.php # A06: SCA — сверка зависимостей с базой известных CVE # (пример для Node-проекта; аналогично trivy/dependency-check) npm audit --production # trivy ищет уязвимые компоненты прямо в образе контейнера trivy image websec-portal-01:latest