Аудит безопасности приложения: что проверяется помимо сканера

Условный пример. Финтех-компания проходит проверку у крупного корпоративного клиента, и в анкете поставщика стоит вопрос: «Проводился ли аудит безопасности приложения?» У команды есть отчёт автоматического сканера на несколько десятков страниц, и в нём нет ни одной критичной находки. Возникает соблазн ответить «да», но один отчёт сканера ещё не подтверждает, что аудит в требуемом заказчиком объёме состоялся.

По сути сканер не входил в личный кабинет под двумя разными ролями. Он не пробовал открыть платёжное поручение другого клиента, подменив идентификатор в запросе к API. Не проверял, можно ли подтвердить операцию, пропустив шаг одобрения. Не читал конфигурацию и не смотрел, как в коде строятся запросы к базе. Если клиент когда-нибудь спросит не «был ли аудит», а «что именно проверили», ответ окажется неловким.

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

Какое решение должен поддержать аудит

Поиск уязвимостей или проверка соответствия

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

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

Для SaaS-компаний, которые регулярно отвечают на анкеты клиентов, этот вопрос особенно важен; как выстроить проверки под такой сценарий, мы разбирали в материале о пентесте для SaaS-компаний.

Письменный контур и разрешение

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

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

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

Почему отчёт сканера не равен аудиту

Что сканер делает хорошо

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

Где он слеп

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

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

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

Архитектура: с чего начинается аудит

Границы доверия и потоки данных

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

В распределённых системах архитектурный этап особенно важен: ошибка часто не в одном сервисе, а в предположении, что «до нас запрос уже проверили». Как планировать проверку в таких системах, описано в руководстве по пентесту микросервисов.

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

Схемы архитектуры, спецификации API и описания ролей — полезная отправная точка, но аудитор проверяет, совпадают ли они с реальностью. Эндпоинт, которого нет в документации, но который отвечает на запросы. Роль, которая в описании «только чтение», а на деле может изменять записи. Сервис, который по схеме недоступен извне, а по факту принимает запросы из интернета. Расхождения между документацией и реальностью — частый источник находок.

Код и конфигурация

Ревью кода по рискам

Если доступ к исходному коду есть, полное построчное чтение обычно не нужно и не реалистично. Эффективнее ревью по рискам: аудитор идёт от карты угроз к местам, где принимаются решения. Как проверяются права? Как строятся запросы к базе данных и вызовы ОС? Как обрабатываются загружаемые файлы? Как формируются и проверяются токены? Где хранятся секреты?

Классический пример — командные инъекции. Требование OWASP ASVS прямо предписывает, что вызовы ОС должны использовать параметризованные запросы или контекстное кодирование командной строки. Найти одну уязвимую точку можно и снаружи. Понять, что в кодовой базе это системный шаблон, удаётся только при взгляде на код.

Конфигурация, секреты и зависимости

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

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

HTTP и политики браузера

Значительная часть защиты веб-приложения реализуется через поведение HTTP. HTTP — протокол без сохранения состояния, и состояние в него добавляют cookie. Поэтому аудитор смотрит, как сессии устанавливаются через Set-Cookie, с какими атрибутами, как устроена аутентификация, не раскрывают ли данные перенаправления, кэширование и междоменное взаимодействие.

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

API и авторизация

Объекты, свойства, функции

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

Проверка на уровне объекта может проходить, а на уровне функции — отсутствовать. Поэтому аудит проверяет все три уровня отдельно, с несколькими ролями и несколькими тестовыми арендаторами, и фиксирует, какие эндпоинты и методы были покрыты.

Контракт API и фактическое поведение

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

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

Подробно о методике для REST-интерфейсов — в материале об оценке безопасности REST API.

Бизнес-логика и ручная проверка

Где автоматизация не помогает

Бизнес-логика — это правила, по которым работает именно ваше приложение. Скидку нельзя применить дважды. Заявку нельзя одобрить, пока не загружены документы. Перевод выше лимита требует второго подтверждения. Возврат нельзя оформить на сумму больше оплаченной. Нарушение этих правил не выглядит как «ошибка» для сканера: каждый отдельный запрос корректен, а проблема в последовательности, значениях или ролях.

Как выглядит ручная проверка

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

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

Стандарты как каркас методики

Что важно, что проверять, как тестировать

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

OWASP ASVS 5.0.0 ближе к базовой линии аудита: он даёт основу для тестирования технических механизмов защиты и стремится выровнять разброс в охвате и строгости проверок на рынке. ASVS рекомендует ссылаться на требования вместе с версией. Например, v5.0.0-1.2.5 означает пятое требование раздела о предотвращении инъекций в главе о кодировании и санитизации версии 5.0.0. Без версии ссылка со временем теряет смысл, потому что нумерация меняется. OWASP WSTG, стабильный выпуск которого — 4.2, а версия 5.0 в разработке, задаёт процедуры тестирования. SP 800-115 описывает планирование, выполнение и действия после выполнения оценки, включая анализ находок, рекомендации по устранению и отчёт.

Вместе это работает так: Top 10 и CWE отвечают на вопрос «что важно», ASVS — «что проверять», WSTG и SP 800-115 — «как тестировать», а управленческие рамки — «что делать с итогом».

1. Решение и контурНазвать решение, которое поддерживает аудит, и зафиксировать среды, роли, API и доступ к коду.
2. ТребованияВыбрать набор требований ASVS с версией, соответствующий риску приложения и цели аудита.
3. ПроверкиСочетать анализ архитектуры, ревью кода, конфигурации, тесты API и ручную проверку логики.
4. ПодтверждениеВоспроизвести каждую находку, отсеять ложные срабатывания, привязать к CWE и требованию ASVS.
5. Отчёт и retestОценить риск в бизнес-контексте, назначить владельцев и повторно проверить исправления.

Классы слабостей вместо списка задач

Рейтинг CWE Top 25 выделяет наиболее опасные и распространённые слабости ПО. MITRE также публикует список слабостей, которые активно эксплуатируются по каталогу CISA KEV, и список слабостей «на грани» включения в Top 25. Для аудитора это сигнал о том, какие первопричины повторяются и привлекают атакующих.

Привязка к CWE меняет разговор об устранении. Вместо исправления одного уязвимого параметра команда спрашивает, нет ли в коде системного шаблона. CWE отмечает, что работа с первопричинами помогает устранять целые классы дефектов, например связанные с инъекциями или безопасностью памяти. В том же направлении указывают предупреждения CISA Secure by Design об устранении межсайтового скриптинга, инъекций команд ОС и обхода каталогов как классов. Отчёт, который группирует находки по классам, даёт инженерному руководству дорожную карту, а не просто список задач.

Приёмка отчёта и повторная проверка

Что означает «находок нет»

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

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

Повторная проверка по тем же требованиям

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

Аудит в управлении рисками

Владельцы и сроки

Аудит приносит пользу, только если находки попадают в управляемый процесс. NIST Cybersecurity Framework 2.0 помогает организациям понимать киберриски и улучшать управление ими; он предлагает профили и информативные ссылки на ресурсы NIST. Если итоги аудита размещены в профиле, согласованном с CSF, становится проще сравнивать текущее и целевое состояние во времени.

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

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

Если вы покупатель, а не разработчик

Позиция CISA Secure by Design добавляет измерение ответственности: поставщики технологий должны брать ответственность за безопасность на уровне руководства, а продукты — поставляться с многофакторной аутентификацией, журналированием и единым входом без доплаты. Для продуктовых команд находки об отсутствии журналов или слабой аутентификации — вопрос проектирования, а не только дефект. Покупателям руководство CISA Secure by Demand помогает задавать эти вопросы при закупке. Обязательства поставщика полезно запросить, но обязательство — это заявление, а не результат аудита.

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