Приложение может быть технически современным и при этом допускать захват учётной записи, обход ролей, доступ к чужим данным или злоупотребление бизнес-функцией.

Автоматический сканер находит часть типовых ошибок, но не понимает права ролей, последовательность операций, взаимосвязь API и бизнес-ограничения. Мы сочетаем ручное тестирование, проверку конфигурации и разбор клиентской и серверной логики — а при доступе к исходному коду добавляем code review.

Обсудить проект Что входит в работы

Работы ведутся по договору и согласованным правилам: контуры, тестовые учётные записи и запрещённые операции фиксируются до старта.

объекты в границах роли
доступ за границей роли

Картирование: точки входа, роли, объекты

Подход

Сканер закрывает типовые классы. Роли, цепочки и бизнес-ограничения — нет

Автоматика хорошо ищет то, что описывается сигнатурой: устаревшая библиотека, отражённый ввод, отсутствующий заголовок. Она не знает, какие объекты принадлежат конкретному пользователю, в каком порядке должны выполняться шаги операции и какие ограничения заданы бизнесом, а не кодом.

Поэтому полноценный анализ сочетает ручное тестирование, проверку конфигурации и изучение клиентской и серверной логики. Если заказчик предоставляет исходный код, добавляется code review — он показывает причину ошибки и ветви, до которых снаружи не добраться.

Сканер при этом остаётся в работе: он даёт быстрый охват типовых классов, а результаты его находок мы верифицируем вручную, чтобы в отчёт не попали ложные срабатывания.

Класс ошибок Сканер Ручная проверка

Устаревшие компоненты, заголовки, TLS находит подтверждает

Инъекции в типовых точках ввода находит углубляет

Доступ к чужим объектам и tenant-изоляция нет находит

Повышение роли и обход прав функций нет находит

Обход лимитов, статусов и последовательности операций нет находит

Цепочки из нескольких некритичных находок нет находит

Оценка по нашей практике проектов, а не по результатам конкретного инструмента.

Метод проверки выбирается на этапе скоупинга

Чёрный ящик

Работаем без учётных записей и документации — так же, как внешний нарушитель. Показывает, что видно снаружи, но оставляет закрытые разделы непроверенными.

Серый ящик

чаще всего

Есть тестовые учётные записи разных ролей и описание функций. Позволяет проверить авторизацию, изоляцию данных и бизнес-логику — то, ради чего услугу и заказывают.

Белый ящик

максимум

К учётным записям добавляется исходный код и архитектура. Даёт наибольшее покрытие и объясняет причину класса ошибок, а не только отдельный симптом.

Что это за услуга

Систематическая проверка приложения, API и его правил доступа

Анализ защищённости веб-приложения — проверка веб-интерфейса, API, механизмов идентификации, бизнес-логики и конфигурации на возможность нарушения конфиденциальности, целостности и доступности. Ниже — типовой объём работ; итоговый состав фиксируется на скоупинге.

Веб-приложения

Публичные и внутренние сервисы, включая те, что доступны только из корпоративной сети.

API

REST, GraphQL, SOAP и другие интерфейсы — как документированные, так и найденные в ходе работ.

Кабинеты и панели

Личные кабинеты, административные панели и B2B-порталы с разными уровнями доступа.

Вход и восстановление

Аутентификация, MFA, SSO и сценарии восстановления доступа — включая обходные пути.

Роли и изоляция

Права на функции и объекты, разграничение между пользователями и tenant-изоляция организаций.

Бизнес-операции

Загрузка файлов, отчёты, платёжные и другие операции, у которых есть цена ошибки.

Клиент и интеграции

Клиентский JavaScript, WebSocket и обмен с внешними системами и партнёрами.

Платформа и секреты

Среда развёртывания и хранение секретов — в объёме, согласованном до начала работ.

Границы услуги

Чем это отличается от смежных работ

Услуги часто путают между собой, а потом обнаруживают, что нужная проверка не выполнялась ни в одной из них. Ниже — что именно закрывает анализ защищённости веб-приложения, а что остаётся за его пределами.

Сканирование

От автоматического сканирования

Сканер проходит по сигнатурам и типовым точкам ввода. Логику ролей и порядок операций он не интерпретирует, а часть находок оказывается ложными.

У нас

Ручная проверка выявляет логические ошибки, обходы авторизации и цепочки, недоступные автоматике, и подтверждает каждую находку.

Инфраструктура

От инфраструктурного анализа

Инфраструктурные работы смотрят на периметр, сетевые сервисы, версии веб-сервера и настройки TLS — то есть на площадку, а не на само приложение.

У нас

Фокус на поведении приложения и API: что происходит с запросом, чьи данные он возвращает и какие ограничения при этом обходятся.

Анализ кода

От code review

Анализ кода объясняет причину ошибки и показывает скрытые ветви, но не отвечает на вопрос, как система ведёт себя в собранном и развёрнутом виде.

Дополняют друг друга

Динамический анализ проверяет работающую систему. При доступе к коду мы совмещаем оба подхода — так находок больше, а причины понятнее.

Если часть работ у вас уже выполнена другой командой — скажите об этом на скоупинге, мы не станем дублировать проверки и потратим время на то, что ещё не закрыто.

Повод для проверки

Когда услуга особенно актуальна

Чаще всего анализ заказывают не «на всякий случай», а под конкретное событие в жизни продукта. Вот ситуации, в которых проверка окупается быстрее всего.

Перед выходом в production Или перед крупным релизом, когда цена отката максимальна.
После изменений в доступе Переделали аутентификацию, роли, платежи или API.
При новой интеграции Внешний IdP, банк, партнёр или мобильный клиент.
Перед аудитом заказчика Или перед публикацией критичного сервиса.
Периодически Для приложений, которые обрабатывают чувствительные данные.
При обновлении модулей Особенно тех, что участвуют в доступе к данным.

Не обязательно каждый раз проверять всё приложение целиком: перед релизом обычно достаточно проверить затронутые функции, а полный анализ повторять по графику.

Результат для бизнеса

Какие задачи решает анализ

Уязвимость в веб-приложении — это не абстрактный риск, а конкретный сценарий: чей-то аккаунт, чьи-то данные или обойдённое финансовое ограничение. Проверка отвечает на эти вопросы до того, как их задаст кто-то другой.

Защита учётных записей

Проверяются вход, MFA, восстановление доступа, сессии и токены, а также устойчивость к автоматизированным атакам — подбору, перебору и массовой регистрации.

Корректная авторизация

Пользователь не должен читать или изменять чужие объекты, повышать свою роль и выходить за границы своей организации. Это проверяется отдельно для каждой роли.

Безопасная обработка данных

Инъекции, загрузка файлов, сериализация, шаблонизаторы, SSRF и другие классы ошибок, из-за которых приложение делает не то, что задумано.

Устойчивость бизнес-логики

Ищутся обходы лимитов, нарушение последовательности шагов, подмена статусов и способы выйти за финансовые ограничения.

Рабочий backlog для разработки

Каждая находка содержит воспроизведение, влияние, причину и вариант исправления — задачу можно взять в спринт без дополнительных исследований.

Программа проверок

Что проверяется или прорабатывается

Базовая программа, которая уточняется под ваше приложение. Если какой-то раздел для вас критичнее остальных, на скоупинге мы перераспределим время в его пользу.

Идентификация и аутентификация

Вход, второй фактор, SSO и сценарии восстановления доступа, включая обходные маршруты.
Авторизация и изоляция данных

Права по функциям и объектам, разграничение ролей и изоляция данных разных организаций.
Сессии и токены

Жизненный цикл сессии, cookies, JWT, OAuth и OIDC: выпуск, срок жизни, отзыв и повторное использование.
Валидация ввода и инъекции

Обработка входных данных на всех уровнях — от параметров запроса до содержимого документов.
Бизнес-логика и антиавтоматизация

Обходы лимитов и статусов, race conditions, защита от массовых автоматических действий.
Файлы, URL и внешние взаимодействия

Загрузка и выдача файлов, обработка ссылок, SSRF и обращения приложения к сторонним системам.
Конфигурация и раскрытие информации

Ошибки настройки, заголовки безопасности, отладочные ответы и лишние данные в выдаче.
API, WebSocket и клиентская часть

Недокументированные методы, различия между веб- и API-контурами, логика и секреты в клиентском коде.

Проверки выполняются безопасно. Влияние подтверждается без повреждения данных и нарушения доступности; операции, которые нельзя выполнять на боевом контуре, фиксируются в правилах работ до старта.

Ход работ

Как проходит проект

Шесть этапов от согласования границ до подтверждения исправлений. Сроки зависят от размера приложения и числа ролей и определяются после скоупинга.

01
Скоупинг и роли

Согласуем контуры, состав API, тестовые учётные записи разных ролей, данные и операции, которые выполнять нельзя.
02
Картирование приложения

Выявляем точки входа, функции, объекты, роли и технологический стек — в том числе то, что не попало в документацию.
03
Автоматизированная проверка

Инструменты дают быстрое покрытие типовых классов ошибок. Каждое срабатывание проверяется вручную, чтобы в отчёт не попал шум.
04
Ручное тестирование

Основная часть работ: авторизация, сессии, бизнес-логика и сложные цепочки, которые собираются из нескольких некритичных находок.
05
Безопасная эксплуатация

Подтверждаем реальное влияние находки без повреждения данных и нарушения доступности сервиса.
06
Отчёт и re-test

Передаём разработчикам воспроизводимые кейсы, отвечаем на вопросы по ходу исправлений и подтверждаем, что уязвимости закрыты.

Правила фиксируются письменноОкно работ, контакты дежурных и стоп-слово на случай влияния на сервис.

Критичное — сразуНаходки высокой критичности передаём до готовности отчёта, не дожидаясь конца работ.

Re-test входит в проектПроверяем исправления по тем же шагам, что и первичные находки.

Отчёт

Что заказчик получает на руки

Отчёт пишется сразу для двух читателей: разработчику нужны шаги и причина, руководителю — риск в терминах данных и бизнес-функций. Поэтому документ состоит из четырёх частей.

Реестр уязвимостей

Критичность, затронутые компоненты, доказательства и последствия каждой находки.
Пошаговое воспроизведение

Запросы, ответы, роли и условия — всё, что нужно разработчику, чтобы повторить сценарий у себя.
Рекомендации

Исправление причины, компенсирующие меры на время доработки и проверки для regression-тестов.
Управленческое резюме

Риски для данных, клиентов и бизнес-функций — без технических деталей, языком принятия решений.

Так выглядит одна находка

Высокая WEB-014

Доступ к документам другой организации через идентификатор в API

Компонент

Метод выдачи документов личного кабинета (роль «менеджер»)

Шаги

Войти под учётной записью организации А
Открыть свой документ и запомнить его идентификатор
Повторить запрос с идентификатором документа организации Б

Влияние

Чтение документов чужой организации без изменения роли и без признаков атаки в логах.

Причина

Права проверяются на уровне функции, но не на уровне объекта: принадлежность документа организации не сверяется.

Исправление

Проверка владельца объекта на серверной стороне для всех методов ресурса, плюс regression-тест на доступ из чужой организации.

Пример условный, не относится к конкретному проекту.

Регулярность

Безопасность приложения меняется с каждым релизом

Новый функционал приносит новые точки входа, рефакторинг переносит проверки прав, а обновление библиотеки может изменить поведение уже проверенного метода. Поэтому разовый анализ фиксирует состояние на дату, а не навсегда.

Рабочая схема простая: критичные функции проверяются до выпуска, полный анализ повторяется по графику и после существенных изменений.

Перед релизом

Точечная проверка изменённых функций: доступ, роли, платежи, новые методы API.

По графику

Полный анализ приложения — обычно раз в год либо чаще для сервисов с чувствительными данными.

После изменений

Внеплановый анализ, если переработана аутентификация, модель ролей или добавлена интеграция.

Цель анализа — помочь команде исправить не отдельный симптом, а причину класса ошибок, чтобы уязвимость не вернулась в следующем релизе.

Обсудить проект

На первом созвоне уточняем контуры, роли и сроки — оценка объёма работ бесплатна.

Анализ защищённости веб-приложений