Аудит безопасности веб-приложения: что проверять и как
Аудит безопасности веб-приложения — это проверка кода, конфигурации и логики на уязвимости по методикам OWASP: этапы, методы, инструменты и ошибки.
Аудит безопасности веб-приложения: зачем он нужен и из чего состоит
Аудит безопасности веб-приложения — это комплексная проверка исходного кода, архитектуры, конфигурации серверов и бизнес-логики, которая выявляет уязвимости и оценивает риск их эксплуатации. Результат — отчёт с приоритетами и планом исправлений.
Веб-приложение — самая открытая часть инфраструктуры компании. Его адрес известен всем, а автоматические сканеры обходят его круглосуточно. В этой статье разберём, какие виды проверок существуют, что входит в аудит, как устроен процесс и как оценивать найденные уязвимости, чтобы потратить ресурсы на самое важное.
Что на самом деле проверяет аудит
Многие воспринимают аудит как «запуск сканера и получение PDF». На деле сканирование — лишь малая часть работы. Полноценная проверка отвечает на три вопроса: что может пойти не так, насколько это вероятно и к каким последствиям приведёт.
Аудит затрагивает несколько уровней: клиентскую часть (JavaScript, формы, работа с cookie), серверную логику (авторизация, обработка запросов, API), базу данных, серверное окружение, сторонние библиотеки и интеграции. Отдельно изучаются процессы: как хранятся секреты, кто имеет доступ к продакшену, как ведутся логи и что происходит при инциденте.
Поводов для проверки несколько. Это требования регуляторов — например, закона о персональных данных 152-ФЗ или стандарта PCI DSS для приёма банковских карт. Это запрос от крупного заказчика, который просит подтвердить уровень защищённости. Или это просто здравый смысл перед запуском нового сервиса либо после смены подрядчика разработки.
Что даёт компании аудит безопасности
- 01
Выявление уязвимостей до того, как их найдут злоумышленники или автоматические сканеры
- 02
Защита персональных данных клиентов и снижение рисков штрафов и судебных исков
- 03
Сохранение репутации: взломанный сайт теряет доверие пользователей, а Яндекс и Google могут показать предупреждение об опасности
- 04
Приоритизированный план работ — команда исправляет сначала критичное, а не всё подряд
- 05
Подтверждение соответствия требованиям заказчиков, партнёров и регуляторов
- 06
Понимание реального уровня зрелости разработки: где процессы работают, а где нужны изменения
Единый язык: методика OWASP
Основой большинства аудитов служит открытый проект OWASP (Open Web Application Security Project). Его главный документ — OWASP Top 10, список наиболее распространённых и опасных классов уязвимостей веб-приложений. Для глубокой проверки используют также OWASP ASVS (стандарт верификации безопасности приложений) и OWASP Testing Guide — пошаговое руководство по тестированию.
Пользоваться общей методикой удобно: заказчик, разработчики и аудиторы говорят на одном языке, а результаты проверок можно сравнивать между собой год от года. Ниже — десять категорий актуального списка OWASP Top 10 в редакции 2021 года, с которых обычно начинается любая проверка.
Десять категорий, которые проверяют в первую очередь
Пользователь видит чужие данные или выполняет действия сверх своих прав.
Слабое шифрование, пароли в открытом виде, данные без HTTPS.
SQL-инъекции, XSS и подмена команд через непроверенный ввод.
Ошибки заложены в архитектуре и бизнес-логике, а не в коде.
Пароли по умолчанию, открытые панели, лишние сервисы, подробные ошибки.
Библиотеки и CMS с известными уязвимостями без обновлений.
Слабые пароли, нет защиты от перебора, небезопасные сессии.
Непроверенные обновления, небезопасная десериализация, уязвимости CI/CD.
Атаку невозможно заметить и расследовать из-за отсутствия журналов.
Сервер делает запросы по адресу, который подставил злоумышленник.
Три подхода к проверке: чёрный, серый и белый ящик
Выбор подхода определяет, сколько информации получает аудитор до начала работ.
Чёрный ящик (black box). Аудитор знает только адрес приложения и действует как внешний злоумышленник. Подход показывает, что видно снаружи, но может пропустить глубоко спрятанные ошибки.
Серый ящик (gray box). Аудитору выдают тестовые учётные записи разных ролей, документацию по API и общую схему системы. Это самый популярный вариант: он имитирует атаку авторизованного пользователя и даёт хороший баланс между глубиной и стоимостью.
Белый ящик (white box). Аудитор получает доступ к исходному коду и конфигурациям. Это самая полная проверка, которая находит уязвимости, недоступные внешнему наблюдателю, — но и самая трудоёмкая.
| Метод | Что анализирует | Сильная сторона | Ограничение |
|---|---|---|---|
| SAST | Исходный код без запуска | Находит ошибки на ранних этапах разработки | Ложные срабатывания, не видит проблем окружения |
| DAST | Работающее приложение снаружи | Выявляет проблемы конфигурации и инъекции | Не видит код и плохо понимает логику |
| SCA | Сторонние библиотеки и зависимости | Быстро показывает известные CVE в зависимостях | Не ищет ошибки в собственном коде |
| IAST | Приложение изнутри во время тестов | Точное указание строки кода с проблемой | Требует внедрения агента в приложение |
| Ручной пентест | Систему целиком, включая бизнес-логику | Находит цепочки уязвимостей и логические ошибки | Дорого и зависит от квалификации специалиста |
Как подготовиться к аудиту
Качество результата во многом зависит от подготовки. Если аудитор тратит первые дни на выяснение, где что находится, у него остаётся меньше времени на сам поиск уязвимостей. Заранее определите границы проверки: какие домены, поддомены, API и мобильные клиенты входят в работу, а какие нет.
Отдельно стоит выбрать среду. Идеально проводить тестирование на стенде, максимально похожем на продакшен, но с обезличенными данными. Если проверка идёт на боевой системе, согласуйте окна работ и ограничения: например, запрет на нагрузочные тесты и массовую рассылку писем.
Ниже — чек-лист того, что обычно запрашивает исполнитель.
Что подготовить до начала аудита
- Тестовые учётные записи для каждой роли (клиент, менеджер, администратор)
- Доступ к тестовому стенду или согласованное окно работ на продакшене
- Доступ к репозиторию кода для подхода «белый ящик»
- Список IP-адресов исполнителя для исключения из блокировок WAF
- Схема архитектуры и перечень внешних интеграций
- Описание API (Swagger / OpenAPI или коллекция запросов)
- Соглашение о границах и правилах проведения работ
- Контакты ответственных со стороны заказчика на случай критичной находки
Как проходит аудит от начала до конца
Процесс аудита можно разделить на несколько последовательных этапов. Их набор зависит от выбранного подхода, но общая логика остаётся одной: от сбора информации к поиску уязвимостей, затем к их подтверждению, оценке и рекомендациям.
Важно, что аудит не заканчивается выдачей отчёта. Ценность появляется, когда найденные проблемы исправлены и проверены повторно.
Этапы аудита безопасности веб-приложения
- 01
Определение границ и целей. Согласуйте перечень доменов, API и сервисов, выберите подход (чёрный, серый или белый ящик), зафиксируйте правила работ и контакты.
- 02
Моделирование угроз. Определите, что именно нужно защищать — платёжные данные, персональные данные, учётные записи — и кто может быть нарушителем: внешний посетитель, клиент, сотрудник.
- 03
Разведка и анализ поверхности атаки. Изучите поддомены, открытые порты, версии ПО, используемые фреймворки, скрытые разделы и точки входа API.
- 04
Автоматизированное сканирование. Запустите SAST, DAST и SCA-инструменты, чтобы быстро найти типовые проблемы и устаревшие зависимости.
- 05
Ручная проверка. Проверьте контроль доступа, бизнес-логику, механизмы сессий и восстановления пароля, загрузку файлов и обработку платежей. Именно здесь находят то, что сканеры пропускают.
- 06
Подтверждение и оценка уязвимостей. Исключите ложные срабатывания, покажите возможность эксплуатации и присвойте каждой находке уровень критичности по шкале CVSS.
- 07
Отчёт и рекомендации. Опишите каждую уязвимость: где найдена, как воспроизвести, чем опасна и как исправить. Добавьте краткое резюме для руководства.
- 08
Повторная проверка. После исправлений убедитесь, что уязвимости закрыты и новые изменения не создали других проблем.
Как оценивать критичность найденного
После проверки обычно остаётся десяток-другой замечаний, и вопрос «с чего начать» становится главным. Универсальный инструмент здесь — шкала CVSS (Common Vulnerability Scoring System), которая присваивает уязвимости числовую оценку от 0 до 10 на основе вектора атаки, сложности эксплуатации и влияния на конфиденциальность, целостность и доступность данных.
Однако цифра — не приговор. Уязвимость средней критичности в модуле оплаты может быть важнее «высокой» в редко используемой админке. Поэтому хороший аудитор учитывает контекст бизнеса и объясняет, почему порядок исправлений именно такой.
Уровни критичности и ориентиры по срокам исправления
Удалённое выполнение кода, обход авторизации, утечка базы. Исправлять немедленно — в течение 24–72 часов.
SQL-инъекции, хранимый XSS, доступ к чужим данным. Срок — до 1–2 недель.
Отражённый XSS, слабая политика паролей, отсутствие защитных заголовков. Срок — до 30 дней.
Раскрытие версий ПО, мелкие недочёты конфигурации. Исправлять в плановых релизах.
Сроки — типичные ориентиры; конкретные значения закрепляются во внутренней политике управления уязвимостями компании.
Почему аудиты бывают неэффективными
Даже качественно проведённая проверка может не принести пользы, если вокруг неё построены неверные ожидания. Чаще всего проблема не в технике, а в организации: неясные границы, формальный подход, отсутствие ответственных за исправление. Разберём типичные ошибки, из-за которых бюджет на аудит тратится впустую.
Частые ошибки при проведении аудита безопасности
Как делать не стоит
- Ограничиться автоматическим сканированием и выдавать его отчёт за аудит
- Проверять только главную страницу и не включать в границы API, личный кабинет и админку
- Тестировать на боевой системе без согласования окон и резервных копий
- Не назначать ответственных за исправление найденных уязвимостей
- Не проводить повторную проверку после исправлений
- Игнорировать зависимости и сторонние плагины, считая их «чужой зоной ответственности»
Как правильно
- 01
Сочетать автоматические инструменты с ручной проверкой бизнес-логики
- 02
Включать в границы все точки входа: веб-интерфейс, API, мобильный клиент, админ-панель
- 03
Согласовывать правила работ письменно и делать резервные копии заранее
- 04
Заводить каждую уязвимость в трекере задач с исполнителем и сроком
- 05
Проверять исправления повторно и фиксировать результат в отчёте
- 06
Встроить SCA и SAST в процесс сборки, чтобы замечать проблемы при каждом релизе
Инструменты и периодичность
Для базовой проверки доступен хороший набор открытых и коммерческих инструментов. OWASP ZAP и Burp Suite применяют для динамического тестирования и ручного анализа запросов. Nmap помогает изучить сетевую поверхность. Для анализа кода используют Semgrep и SonarQube, для проверки зависимостей и контейнеров — OWASP Dependency-Check и Trivy. Эти инструменты не заменяют эксперта, но экономят время и закрывают типовые проблемы.
Периодичность проверок зависит от динамики разработки. Для стабильного сайта достаточно полного аудита раз в год и точечных проверок после значимых изменений. Для продукта, который выпускает релизы еженедельно, автоматические проверки встраивают прямо в конвейер сборки, а ручной пентест проводят раз в полгода.
Не забывайте и про внешние сигналы. Яндекс Вебмастер и Google Search Console уведомляют о подозрительном контенте и взломе сайта. Подключите оба сервиса и настройте уведомления: иногда именно так компания узнаёт о проблеме раньше всех. Дополнительную защиту периметра дают WAF и средства защиты от DDoS, например Yandex Smart Web Security или аналогичные решения других провайдеров.
Итоги: с чего начать аудит безопасности
- 01
Определите границы проверки и выберите подход: чёрный, серый или белый ящик
- 02
Опирайтесь на методики OWASP Top 10 и ASVS как на общий язык с исполнителем
- 03
Сочетайте автоматические инструменты (SAST, DAST, SCA) с ручным тестированием логики
- 04
Приоритизируйте уязвимости по CVSS с учётом ценности данных и бизнес-контекста
- 05
Назначьте ответственных, зафиксируйте сроки и обязательно проведите повторную проверку
- 06
Встройте проверки в разработку и пересматривайте защиту минимум раз в год
Первый аудит почти всегда выявляет больше проблем, чем ожидает команда, — и это нормально. Важно не количество находок, а то, что вы узнали о них раньше злоумышленников и получили понятный план действий. Начните с самого критичного сервиса, исправьте найденное, закрепите результат повторной проверкой и постепенно сделайте безопасность частью обычного цикла разработки.
Часто задаваемые вопросы
Аудит шире: он охватывает код, архитектуру, конфигурацию, процессы и документацию. Пентест — это имитация атаки, цель которой показать, можно ли реально проникнуть в систему. На практике пентест часто входит в аудит как один из этапов.
Минимум раз в год и после каждого крупного изменения: смены архитектуры, подключения платежей, выхода новой версии с большим числом функций. Автоматические проверки (SAST, SCA) стоит встроить в процесс разработки и запускать при каждой сборке.
Для небольшого сайта или сервиса с несколькими ролями обычно хватает одной-двух недель. Крупные платформы с множеством интеграций проверяют от трёх до восьми недель, включая повторную проверку после исправлений.
Базовую проверку можно сделать своими силами с помощью OWASP ZAP, Semgrep, Trivy и чек-листов OWASP. Но внешний взгляд выявляет то, что команда разработки не замечает: ошибки бизнес-логики, цепочки уязвимостей и слабые места в инфраструктуре.
Косвенно да. Если сайт взломан, Яндекс и Google могут пометить его как опасный, показать предупреждение в браузере и понизить в выдаче. Уведомления о проблемах приходят в Яндекс Вебмастер и Google Search Console. Использование HTTPS также считается базовой гигиеной для ранжирования.
Узнайте, где ваше веб-приложение уязвимо, до того как это сделают злоумышленники
Получите отчёт с приоритизированным списком уязвимостей и конкретными рекомендациями по устранению каждой из них
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
Проверка по методикам OWASP и CVSS
