Проверка веб-приложения на уязвимости: объём, метод и доказательства, которые выдерживают проверку

Представим гипотетический B2B-сервис для работы с заявками. У него есть веб-интерфейс, публичный REST API для интеграций, выгрузка отчётов в CSV, ночное фоновое задание, которое собирает сводки для руководителей, и кэш перед частью эндпоинтов. Клиенты сервиса — разные компании, и каждая работает в своём арендаторе. Перед крупным релизом, в котором появляется новая роль «администратор организации», технический директор просит «проверить приложение на уязвимости». Сканер проходит по страницам и возвращает десяток замечаний о заголовках. Но главные вопросы остаются без ответа: может ли пользователь одной компании получить отчёт другой через выгрузку, видит ли обычный сотрудник поля, предназначенные администратору, и не отдаёт ли кэш чужие данные после смены сессии.

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

Что на самом деле входит в проверку веб-приложения

Объём оценки защищённости шире страниц, которые видит пользователь. OWASP Application Security Verification Standard (ASVS) описывает себя как основу для проверки технических мер защиты приложения, а также тех мер окружения, на которые приложение опирается. На практике в разговор об объёме должны попасть код и бизнес-логика, аутентификация и управление сессиями, API, конфигурация на уровне HTTP и вспомогательные компоненты, от которых зависит приложение.

Инвентаризация активов до первого запроса

Тест начинается не со сканера, а со списка. Команда фиксирует домены и окружения, веб-интерфейс и мобильные клиенты, если они работают с тем же бэкендом, публичные и внутренние API, механизмы выгрузки и импорта, фоновые задания, очереди, вебхуки, кэши и CDN, сторонние интеграции и панели администрирования. Отдельно стоит записать, какие из этих частей обрабатывают данные разных клиентов и какие роли к ним обращаются. Без такого списка оценка проверит то, что заметно, и пропустит то, что важно.

Таблица ниже помогает принять решение по каждой границе до того, как она попадёт в план.

Разрешение и границы работ

Тестировать можно только собственные системы или системы, на проверку которых владелец дал явное письменное разрешение. Хороший план называет приложения, окружения и интерфейсы в объёме, роли и тестовые учётные записи, явные исключения, окна тестирования и контакты для экстренной связи. В нём же фиксируются правила обращения с данными: можно ли работать в продуктивной среде, какие действия недопустимы и что делать, если обнаружатся реальные персональные данные. Критерии приёмки тоже стоит записать заранее — о них речь пойдёт ниже.

Роли, аутентифицированные состояния и границы доверия

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

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

Аутентификация — не авторизация

Аутентификация отвечает на вопрос «кто вы», авторизация — на вопрос «что вам разрешено делать с этим конкретным объектом, полем или функцией». Успешный вход ничего не говорит о втором. Опасное допущение — считать, что если пользователь вошёл и интерфейс показывает ему только его кнопки, то доступ уже ограничен. Сервер должен принимать решение о доступе на каждом запросе, исходя из личности, роли и принадлежности объекта, а не из того, что клиент не отрисовал ссылку.

Изоляция арендаторов за пределами видимого API

В SaaS-продукте изоляция арендаторов — отдельный предмет проверки. Недостаточно убедиться, что эндпоинт чтения карточки возвращает ошибку на чужой идентификатор. Те же данные могут уйти через выгрузку, где фильтр по арендатору реализован отдельно; через фоновое задание, которое формирует отчёт с системными правами; через поиск или подсказки автодополнения; через кэш, ключ которого не учитывает пользователя или арендатора. В нашем гипотетическом сервисе выгрузка и ночная сводка — как раз те места, где логика изоляции может быть реализована заново и поэтому заслуживает отдельной проверки под двумя арендаторами.

Три вопроса авторизации в API: объект, свойство, функция

OWASP API Security Top 10 2023 разделяет несколько категорий, которые на практике легко смешать. Их полезно держать раздельно, потому что каждая требует своих тестов и своего исправления. Порядок перечисления ниже не говорит ни о распространённости, ни о важности.

Уровень объекта и уровень свойства

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

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

Уровень функции

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

Потребление ресурсов и чувствительные бизнес-потоки

Две другие категории OWASP API Security Top 10 2023 легко спутать, хотя они о разном. Неограниченное потребление ресурсов означает, что API не ограничивает объём, частоту или стоимость запросов: размер страницы, число элементов в выгрузке, тяжёлые фильтры, вызовы платных внешних сервисов. Неограниченный доступ к чувствительным бизнес-потокам означает, что легитимную функцию можно использовать автоматизированно и в масштабе, который вредит бизнесу: массовая регистрация, скупка, рассылка приглашений, перебор промокодов. Первое — вопрос ресурсов и стоимости, второе — вопрос злоупотребления бизнес-процессом, и тесты и меры защиты у них разные. Подробнее о том, как строится такая оценка для API, — в разборе оценки защищённости REST API.

Бизнес-логика, которую сканер не оценит

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

Шаги процесса, лимиты и переходы состояний

Практические вопросы для проверки звучат так. Можно ли пропустить шаг или выполнить шаги в другом порядке? Можно ли повторить операцию, которая должна выполняться один раз? Соблюдаются ли лимиты при параллельных запросах? Что происходит с объектом при переходе из одного статуса в другой, если запрос пришёл в неожиданный момент? Совпадает ли значение, которое пересчитывает сервер, с тем, что прислал клиент? Каждый такой вопрос выводится из описания продукта, поэтому тестировщику нужны документация, тестовые данные и доступ к человеку, который может сказать, что считается правильным. О том, как определять объём и выбирать исполнителя для такой работы, — в материале о тестировании бизнес-логики.

HTTP-контроли, сессии и политики браузера

Уровень HTTP — хорошая отправная точка: его проверка малорисковая и быстро показывает, насколько аккуратно настроено приложение. Но это отправная точка, а не итог.

Состояние сессии — решение уровня приложения

HTTP как протокол не связывает запросы между собой: каждый запрос несёт всё, что нужно для его обработки. Состояние добавляет приложение — чаще всего через cookie с идентификатором сессии, данные которой сервер хранит у себя, или через токены. Обычные серверные сессии поверх HTTP — стандартная практика. Поэтому тестируется не протокол, а то, как приложение создаёт, привязывает, обновляет и завершает сессию: меняется ли идентификатор после входа, аннулируется ли сессия при выходе и смене пароля, ограничен ли срок её жизни, выставлены ли у cookie атрибуты Secure, HttpOnly и подходящий SameSite, не продолжает ли работать старый токен после понижения роли.

Заголовки как свидетельство, а не доказательство

Современные браузеры предлагают механизмы, которые приложение должно правильно настроить. Content Security Policy определяет, какие ресурсы может загружать страница, и помогает смягчать XSS и внедрение данных. CORS управляет тем, как сайт отвечает на межсайтовые запросы, и слишком широкая политика вместе с передачей учётных данных может открыть ответы чужому источнику. Cross-Origin Resource Policy защищает ресурсы от определённых межсайтовых загрузок, а Permissions Policy ограничивает функции браузера, доступные коду страницы. Стоит проверить и обработку ошибок: единообразны ли ответы и не раскрывают ли они лишнего. При этом наличие заголовка ещё не доказывает защищённость. Строгий CSP не исправит ошибку авторизации, а корректный CORS не защитит выгрузку, которая не проверяет арендатора.

Ширина сканирования, глубина ручной работы и подтверждение последствий

Руководство NIST по техническому тестированию безопасности SP 800-115 разделяет сканирование уязвимостей, тестирование на проникновение и оценку защищённости как связанные, но разные виды работ и подчёркивает, что у каждой техники есть преимущества и ограничения. Для веб-приложений это различие имеет прямой практический смысл.

Что даёт и чего не даёт каждый подход

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

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

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

Как сочетать подходы в одной оценке

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

Роли стандартов: Top 10, ASVS и WSTG

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

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

Версионированные требования ASVS как критерии приёмки

ASVS задуман, чтобы выровнять охват и строгость проверок, поэтому хорошо отвечает на вопрос, что означает «проверка завершена». Команда выбирает требования, применимые к её архитектуре, и для каждого фиксирует результат: выполнено, не выполнено или неприменимо. Идентификатор требования состоит из номеров главы, раздела и требования, и проект предупреждает, что эти номера могут меняться между версиями. Поэтому версию указывают явно: например, v5.0.0-1.2.5 — это пятое требование раздела Injection Prevention в главе Encoding and Sanitization версии 5.0.0. Идентификатор без версии становится неоднозначным по мере развития стандарта. Списки требований доступны в машиночитаемых форматах, включая CSV и JSON, поэтому их удобно загрузить в трекер и сравнивать результаты между релизами.

WSTG как руководство, CWE как язык первопричин

OWASP Web Security Testing Guide описывает, как тестировать отдельные области веб-приложения: аутентификацию, авторизацию, управление сессиями, обработку ввода и бизнес-логику. Это руководство по методике, а не критерий приёмки. Каталог MITRE CWE помогает описывать находки на уровне первопричины: если каждая подтверждённая проблема сопоставлена с записью CWE, можно устранять целый класс дефектов, а не отдельный экземпляр. Руководство NIST SP 800-115 полезно для структуры процесса — планирования, проведения, анализа и устранения, — а веб-специфичные техники разумно брать из актуальных материалов OWASP, поскольку документ NIST опубликован в 2008 году.

Доказательства, приоритизация и повторная проверка

Ценность тестирования возникает на последнем этапе, когда находка превращается в исправление, подтверждённое повторной проверкой.

Из чего состоит полезная находка

Находка, с которой разработчик может работать, содержит роль и арендатора, под которыми она воспроизводится; точный запрос и ответ или шаги в интерфейсе; затронутые объекты, поля или функции; наблюдаемый результат и ожидаемое поведение; ссылку на запись CWE и версионированное требование ASVS; оценку последствий в контексте именно этого продукта. Сырой вывод сканера без разбора — не находка, а материал для анализа.

Как расставлять приоритеты

Разумное правило сортировки опирается на три входа: техническую тяжесть слабости, свидетельства реальной эксплуатации этого класса слабостей и влияние на конкретный актив. MITRE публикует списки наиболее опасных слабостей, а также слабостей, связанных с каталогом CISA Known Exploited Vulnerabilities, и это помогает оценить второй вход. Ни один из этих источников не предписывает единую формулу, поэтому организации стоит записать собственное правило и применять его последовательно. Для многоарендного продукта нарушение изоляции арендаторов, как правило, заслуживает высокого приоритета из-за влияния на бизнес, даже если технически оно выглядит простым.

Повторная проверка и закрытие

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

1. ПодтверждениеВоспроизвести проблему с записанной ролью, арендатором и запросом
2. ИсправлениеУстранить первопричину на сервере, а не скрыть элемент интерфейса
3. ПовторВыполнить исходную проверку тем же способом и с теми же данными
4. Соседние путиПроверить родственные методы, выгрузку, фоновое задание и кэш
5. ЗакрытиеЗафиксировать доказательство и остаточный риск в трекере

Как заказать оценку веб-приложения

Цель ASVS выровнять охват и строгость проверок работает на покупателя: стандарт даёт общую мерку для сравнения предложений, которые иначе описывают работу в несопоставимых терминах. Руководство CISA Secure by Demand исходит из того же принципа — требовать от поставщика проверяемых доказательств. Оно написано для закупки продуктов, но применимо и к услугам тестирования безопасности.

Вопросы к исполнителю

• Какая версия ASVS и какие требования будут проверены и как будет отражён результат по каждому из них?
• Какие роли, арендаторы и аутентифицированные состояния войдут в ручное тестирование?
• Входят ли в объём API, выгрузки, фоновые задания и кэши, а не только видимый интерфейс?
• Какие области WSTG покрываются вручную, а какие проверки автоматизированы?
• Как оформляются объём, тестовые учётные записи, исключения и письменное разрешение?
• Будет ли каждая находка сопоставлена с CWE и версионированным требованием ASVS и снабжена доказательствами воспроизведения?
• Включена ли повторная проверка и как документируется остаточный риск?
• Как защищаются конфиденциальные данные и стабильность продуктивной среды во время работ?

Тревожные признаки — отчёт, состоящий в основном из вывода сканера; находки без ссылок на первопричину или требование; отсутствие повторной проверки; отсутствие определённой процедуры получения разрешения. Любые заявления исполнителя о сертификации или прошлых результатах стоит проверять независимо.

Чем результат пентеста является и чем не является

Тест на проникновение — это снимок защищённости в согласованном объёме на определённый момент. Он показывает, какие слабости найдены и подтверждены, как они связаны между собой и что исправлено после повторной проверки. Пентест не является сертификацией, аттестацией или заключением о соответствии и не может гарантировать отсутствие уязвимостей. Изменения в коде, конфигурации и интеграциях после проверки создают новую поверхность, поэтому лёгкие автоматические проверки стоит встроить в процесс поставки, а глубокую ручную оценку повторять перед крупными релизами и после существенных изменений архитектуры; точную периодичность организация определяет сама. Если прикладное тестирование нужно связать с более широкой программой — от архитектуры до процессов разработки, — полезен разбор аудита безопасности приложений.

Для гипотетического сервиса из начала статьи результатом хорошей оценки был бы не список заголовков, а ответ на исходные вопросы: изолированы ли арендаторы в API, выгрузке, ночной сводке и кэше, соответствуют ли права новой роли замыслу и какие исправления подтверждены повторной проверкой. Pentest.red может помочь определить такой объём и провести авторизованную оценку; начать удобно с описания контура пентеста — систем, ролей, доступов и ограничений.