Три месяца назад на архитектурном ревью финтех-проекта я наткнулся на штуку, которую хоть в учебник вставляй: JWT-токены валидировались на API Gateway, но ни один из четырёх backend-микросервисов не проверял подпись самостоятельно. Semgrep молчал - в коде формально всё чисто. DAST-сканер не дошёл до внутренних endpoint'ов. IDOR нашёлся только при ручном анализе trust boundaries, когда стало понятно, что ownership-модель в data layer не совпадает с моделью авторизации на gateway. Это архитектурная уязвимость - класс дефектов, который не видит ни один автоматизированный инструмент Application Security тестирования веб-приложений. А русскоязычный контент по теме на 90% сводится к перечислению SAST/DAST-сканеров и пересказу описаний инструментов. Разбираю, как тестировать безопасность приложений на уровне проектирования - с конкретными командами, abuse cases и привязкой к kill chain.
Архитектурные уязвимости и цепочка атаки на веб-приложение
Архитектурная уязвимость - не баг в коде, а дефект в дизайне системы. Сканер не найдёт отсутствие rate limiting на API, криво нарисованную trust boundary или микросервис, который безусловно доверяет данным от соседа. При этом именно такие дефекты дают атакующему полную цепочку от initial access до импакта. Подробнее - в нашем подробном разборе пентест веб-приложений.
Как выглядит цепочка атаки через архитектурный дефект в терминах MITRE ATT&CK:
- Recon: Vulnerability Scanning (T1595.002, Reconnaissance) - атакующий сканирует публичные endpoint'ы, находит неприкрытый Swagger UI или GraphQL Introspection.
- Initial access: Exploit Public-Facing Application (T1190, Initial Access) - эксплуатация injection или IDOR через публичный API.
- Credential access: атакующий использует Credentials In Files (T1552.001) или Password Guessing (T1110.001) для получения токенов.
- Persistence: Web Shell (T1505.003, Persistence) или Valid Accounts (T1078) через захваченные сессии.
- Impact: Stored Data Manipulation (T1565.001, Impact) - модификация данных в БД через скомпрометированный микросервис.
По данным Verizon DBIR 2025, эксплуатация уязвимостей выросла на 34% год к году и составляет 20% подтверждённых инцидентов. 88% базовых атак на веб-приложения включали использование украденных учётных данных. Broken Access Control (A01:2021 по OWASP Top 10, где 94% приложений были затронуты при тестировании) - архитектурная проблема по своей природе, не кодовая.
Threat modeling веб-приложения: abuse cases вместо чеклистов
Threat modeling - точка, где разница между AppSec-инженером и оператором сканера становится принципиальной. Сканер проверяет "что есть". Threat model отвечает на вопрос "что может пойти не так и почему".[Применимо: grey box / white box, любая инфраструктура - от монолита до микросервисной архитектуры]
Практический подход к threat modeling для веб-приложения:
Шаг 1. Data Flow Diagram (DFD). Рисуете схему потоков данных: откуда приходят запросы, через какие компоненты проходят, где хранятся. Инструменты: OWASP Threat Dragon (open source, активно поддерживается), draw.io или текстовый формат. Критично обозначить trust boundaries - линии, за которыми уровень доверия к данным меняется.
Шаг 2. Идентификация abuse cases. Для каждого trust boundary задаёте три вопроса:
- Что произойдёт, если входные данные на этой границе не валидируются?
- Может ли пользователь с ролью A получить доступ к данным роли B через этот компонент?
- Что если внутренний сервис вызывается напрямую, минуя gateway?
Пример из практики: в трёхуровневой архитектуре (frontend -> API Gateway -> микросервисы -> БД) типичный abuse case - обход авторизации через прямой вызов микросервиса. Если gateway проверяет JWT, но сервис заказов принимает любой запрос от gateway без повторной проверки claims - IDOR в production. Это A01:2021, и SAST его не найдёт, потому что каждый компонент по отдельности корректен.
SAST DAST инструменты: decision tree для архитектурного тестирования
Ни SAST, ни DAST по отдельности не решают задачу анализа защищённости веб-приложений на уровне архитектуры. Каждый инструмент покрывает свою часть поверхности, и понимание того, что именно он видит (а что - нет), для AppSec пентеста критично.
SAST: статический анализ на уровне архитектуры
Механика: SAST парсит исходный код, строит Abstract Syntax Tree (AST), проводит control flow и data flow analysis, затем проверяет код против набора правил. По данным Palo Alto Networks, SAST выявляет injection flaws, XSS, insecure data handling и паттерны из OWASP Top 10 на стадии написания кода.Что находит: injection-паттерны (SQLi, XSS, CSRF), hardcoded credentials, использование слабых криптоалгоритмов, небезопасную обработку данных.
Что НЕ находит: логические ошибки авторизации, проблемы с trust boundaries между сервисами, business logic flaws, ошибки конфигурации runtime-окружения.
Инструменты для архитектурного уровня:
Semgrep (open source, обновления еженедельно) позволяет писать кастомные правила, которые ближе к архитектурным проверкам, чем стандартные наборы. Например, правило для поиска endpoint'ов без проверки авторизации.
Checkov (open source, Bridgecrew/Palo Alto) - статический анализ IaC (Terraform, CloudFormation, Kubernetes-манифесты) на предмет security misconfigurations (A05:2021).
Пример кастомного правила semgrep для поиска endpoint'ов Flask без декоратора авторизации:
YAML:
rules:
- id: flask-endpoint-no-auth
patterns:
- pattern: |
@app.route(...)
def $FUNC(...):
...
- pattern-not: |
@login_required
def $FUNC(...):
...
message: "Endpoint без проверки авторизации"
severity: WARNINGsemgrep --config path/to/rules.yaml . в корне проекта.Ограничения SAST в архитектурном тестировании: главная боль - false positives. По данным EndorLabs, SAST часто не может определить, достижим ли обнаруженный уязвимый путь в runtime. На проектах с 500k+ LOC false positive'ы - основная причина, по которой разработчики начинают игнорировать алерты. И это уже проблема не инструмента, а процесса.
DAST: тестирование с позиции атакующего
Механика: DAST отправляет вредоносные запросы к работающему приложению и анализирует ответы - имитация black box атаки.Что находит: server misconfiguration, authentication flaws, runtime-уязвимости (открытые debug-эндпоинты, verbose error messages), injection через HTTP.
Что НЕ находит: уязвимости в коде без внешних проявлений, проблемы межсервисного взаимодействия (DAST видит только внешнюю границу), business logic flaws.
Burp Suite Pro (коммерческий, PortSwigger, активно поддерживается) - де-факто стандарт для ручного и полуавтоматизированного AppSec пентеста. Crawler + Scanner + расширение через BApps. ZAP (Zaproxy, open source, Checkmarx, ранее OWASP ZAP) - бесплатная альтернатива, интегрируется в CI/CD. При выборе DAST-инструмента смотрите на поддержку спецификаций API (OpenAPI/Swagger) - без этого покрытие будет неполным.
Ограничение DAST для архитектурного тестирования: DAST тестирует то, что атакующий видит снаружи. Если архитектурная уязвимость спрятана за двумя слоями сервисов - DAST её не достанет. По данным CircleCI, DAST обнаруживает уязвимости поздно в SDLC, когда их исправление обходится значительно дороже.
SCA: software composition analysis с reachability
По данным OWASP (A06:2021 - Vulnerable and Outdated Components), использование компонентов с известными уязвимостями стабильно входит в десятку рисков. Большинство современных приложений содержат больше стороннего кода, чем собственного.Ключевое отличие SCA-инструментов в 2026 году - reachability analysis: проверка, вызывается ли уязвимая функция в зависимости вашим кодом. Без reachability SCA генерирует сотни алертов, из которых реальную угрозу представляют единицы.
Инструменты: Endor Labs, Snyk, Trivy (open source). Критерий выбора - наличие reachability analysis и интеграция с вашим package manager.
Trade-off таблица: выбор подхода к тестированию безопасности приложений
| Критерий | SAST | DAST | IAST | SCA |
|---|---|---|---|---|
| Когда применять | Этап написания кода, в CI/CD | Staging/pre-production, после деплоя | QA-среда при функциональном тестировании | При каждом изменении зависимостей |
| Что находит | Injection, hardcoded secrets, unsafe patterns | Misconfig, auth flaws, runtime errors | Injection + runtime с привязкой к строке кода | Уязвимые зависимости, лицензионные риски |
| Архитектурные flaws | Нет (только кодовый уровень) | Частично (внешняя граница) | Частично (один сервис) | Нет |
| False positives | Высокий | Низкий | Низкий | Высокий без reachability |
| Ограничения | Не видит runtime и конфиг | Не видит код и межсервисное | Требует runtime agent, performance overhead | Не видит custom code |
| Когда НЕ использовать | Как единственный инструмент AppSec | Для анализа бизнес-логики | В production из-за производительности | Без reachability на крупных проектах |
Decision tree для выбора подхода:
- Пишете новый код -> SAST в IDE + SCA в CI/CD
- Готовите релиз -> DAST на staging
- Архитектурный ревью -> threat model + ручной анализ trust boundaries
- Подозреваете business logic flaw -> ручной AppSec пентест (Burp Suite Pro + abuse cases)
- Проверяете зависимости -> SCA с reachability
Тестирование безопасности на уровне архитектуры: пошаговый процесс
Требования к окружению
- ОС: Kali Linux 2024.x+ или Ubuntu 22.04+. macOS допустим для Burp Suite и semgrep
- RAM: минимум 8 ГБ (semgrep + Burp Suite одновременно), рекомендуется 16 ГБ для проектов >100k LOC
- Зависимости: Python 3.10+, pip, Docker (для запуска тестовых сервисов), semgrep CLI (
pip install semgrep), Checkov (pip install checkov) - Сеть: доступ к тестируемому приложению. Для DAST - приложение развёрнуто и доступно по HTTP/HTTPS
- Инструменты: Burp Suite Pro (коммерческий, $449/год на одного пользователя) или ZAP (бесплатный). Semgrep CLI (бесплатный). Checkov CLI (бесплатный)
Маппинг trust boundaries и поверхности атаки
Задача: определить, где в архитектуре проходят границы доверия, и проверить, что на каждой границе данные валидируются и авторизация проверяется.[Применимо: grey box / white box, внутренний аудит]
- Запросите у команды разработки архитектурную диаграмму. Если её нет (а её обычно нет) - постройте по API-документации и конфигу reverse proxy (
nginx.conf, Envoy config, API Gateway routes). - Для каждого сервиса определите: принимает ли он запросы от других сервисов напрямую? Если да - есть ли проверка аутентификации на этом уровне?
- Проверьте через
curlили Burp Suite: можно ли обратиться к внутреннему сервису напрямую, минуя gateway:
Bash:
# Прямой запрос к микросервису, минуя API Gateway
curl -X GET http://orders-service:8080/api/orders/12345 -H "Content-Type: application/json"
# Ответ 200 без JWT = trust boundary нарушена- Проверьте IDOR: замените идентификатор ресурса (order ID, user ID) в запросе на чужой. Если сервис отдаёт чужие данные - авторизация реализована на неправильном уровне (A01:2021).
Тестирование межсервисного взаимодействия и API
[Применимо: internal audit, grey box / white box]Здесь DAST-сканеры бесполезны - они не видят внутренние вызовы. Нужен ручной анализ:
- Аутентификация между сервисами. Проверьте, используют ли микросервисы mTLS или service-to-service токены. Если внутренние вызовы идут по plain HTTP без auth - любой скомпрометированный контейнер в кластере получает доступ ко всем сервисам. Это прямая эксплуатация trust boundary: от T1190 (Initial Access) к Valid Accounts (T1078).
- Input validation на каждом сервисе. Типичный антипаттерн: gateway валидирует input, а backend-сервис принимает сырые данные. Проверяется отправкой вредоносного payload напрямую к backend-сервису (A03:2021 - Injection).
- Rate limiting и abuse prevention. Если rate limiter стоит только на gateway - атакующий, попавший во внутреннюю сеть, ничем не ограничен. Проверяется через Burp Intruder или простым скриптом с множественными запросами.
- Схема авторизации. Где именно проверяется, что пользователь A видит только свои данные? На gateway? На каждом сервисе? В БД через row-level security? Архитектура, где авторизация существует только на одном уровне - потенциальная дыра. Проверяется анализом кода сервисов (semgrep с кастомными правилами) + ручной проверкой через Burp с подменой JWT claims.
Secure SDLC: встраивание архитектурного тестирования в пайплайн
DevSecOps и shift-left security - это не "поставили SAST в CI/CD и забыли". Архитектурное тестирование безопасности веб-приложений требует отдельных точек контроля на каждом этапе.На этапе проектирования (до кода):
- Threat model для каждого нового сервиса или значимого изменения API-контракта
- Review trust boundaries при добавлении нового микросервиса в кластер
- Abuse case analysis для каждой бизнес-функции (оплата, регистрация, смена пароля)
- SAST (semgrep) - при каждом pull request. Фокус на кастомных правилах, специфичных для вашей архитектуры, а не только на стандартных наборах
- SCA (Trivy, Snyk) - при изменении dependency-файлов. Обязательно с reachability analysis
- IaC-сканирование (Checkov) - при изменении Terraform или Kubernetes-манифестов. Закрывает A05:2021 (Security Misconfiguration) на уровне инфраструктуры. Запуск:
checkov -d /path/to/terraform
- DAST (ZAP или Burp Suite) на staging-среде
- Ручной AppSec пентест для критических изменений - новые потоки аутентификации, платёжные интеграции, изменения в модели данных
- Полный архитектурный ревью trust boundaries
- Обновление threat model
- Проверка, не появились ли новые сервисы, обходящие стандартную модель авторизации
AppSec инструменты 2026: ограничения и когда автоматика бесполезна
За последний год я провёл 12 архитектурных ревью веб-приложений - в 10 из них критические уязвимости сидели именно на уровне дизайна, не кода. JWT без проверки подписи внутри сервисов, IDOR из-за отсутствия ownership-модели в data layer, rate limiting только на gateway. Ни один из этих дефектов не был бы найден сканером.
Индустрия двигается к AI-driven тестированию, и это обнадёживает: AI-агенты уже строят многошаговые цепочки атак, находят authorization bypass через серию запросов. Но архитектурные дефекты - это ошибка в голове проектировщика, не паттерн в коде. Пока AI не может прочитать DFD и спросить: "а почему этот сервис доверяет входным данным без валидации?" - роль AppSec-инженера с навыком threat modeling только растёт. Большинство AppSec-программ в российских компаниях сводится к запуску SAST в CI/CD и ежегодному пентесту - и именно поэтому архитектурные IDOR и broken access control обнаруживаются уже в production, когда цена исправления максимальна. Те, кто начинает с threat model на этапе проектирования, тратят на AppSec пентест перед релизом в разы меньше времени - архитектурные дефекты уже устранены, а сканеру остаётся только мелочь. Если хочешь отработать полную цепочку от abuse case до эксплуатации IDOR в микросервисной архитектуре - на HackerLab (https://hackerlab.pro) есть таски в категории web, где подобные сценарии собираются end-to-end без подсказок.
Последнее редактирование модератором:
