Аудит безопасности веб-приложений: как проверить сайт, личный кабинет и API до инцидента

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

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

О каких веб-приложениях идёт речь

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

Свои приложения

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

Коробочные системы, развёрнутые у вас

CMS, CRM, корпоративные порталы, self-hosted-сервисы. Код чужой, но ваши — версия, настройки, права доступа, плагины и всё, что вокруг. Уязвимость здесь обычно не в самом продукте, а в том, как его развернули: не обновили, оставили дефолтный пароль, открыли админку наружу, поставили сомнительный модуль.

Внешние облачные сервисы

Их аудировать нельзя — приложение вам не принадлежит. Зато можно и нужно проверить то, что относится к вам: кто имеет доступ, какие права у сотрудников и подрядчиков, что уходит в сервис через интеграцию и какие ключи для этого используются.

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

Когда веб-приложение пора проверять

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

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

Отдельный триггер — ощущение «вроде всё работает, но мы не понимаем, как». Это не паранойя, это нормальный повод посмотреть.

Что именно проверяется

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

Периметр

Сначала описываем, что вообще входит в проверку: домены и поддомены, личные кабинеты, админпанели, API, внутренние веб-сервисы, тестовые среды. Забытый поддомен со старой версией приложения — классическая точка входа, о которой в компании уже никто не помнит.

Техника

Версии библиотек и фреймворков, настройки сервера, заголовки, шифрование, обработка пользовательского ввода, загрузка файлов, работа с сессиями и токенами. Часть этого находит автоматика, часть приходится проверять руками.

Логика

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

Методически проверка опирается на общепринятые отраслевые практики: OWASP Top 10 — список ключевых рисков веб-приложений, OWASP WSTG — методику самого тестирования. Если приложение работает с персональными данными, платежами или относится к финансовой сфере, добавляются требования 152-ФЗ, PCI DSS или ГОСТ 57580 — набор зависит от того, что именно обрабатывает система.

Услуга ОБИТ

Аудит информационной безопасности

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

Что находят в веб-приложениях чаще всего

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

Уязвимость	Как выглядит на практике	Чем оборачивается для бизнеса
Нарушение контроля доступа	Пользователь меняет номер заказа в адресной строке и открывает чужой. Или обычный аккаунт вызывает метод, который задумывался для администратора.	Утечка клиентских данных без всякого взлома — достаточно любопытства одного пользователя.
Инъекции	Данные из формы или параметра запроса попадают в SQL-запрос или системную команду без проверки.	Выгрузка всей базы, подмена данных, в тяжёлых случаях — управление сервером.
Слабые места в сессиях	Токен живёт вечно, не сбрасывается при выходе, передаётся или хранится небезопасно.	Перехваченная сессия продолжает работать месяцами, в том числе у уволенного сотрудника.
Незащищённые API	Метод отдаёт больше данных, чем показывает интерфейс, не проверяет права или не ограничивает частоту запросов.	Клиентскую базу выкачивают через тот же API, которым пользуется мобильное приложение.
Устаревшие компоненты	Библиотеки и фреймворки, которые не обновляли годами и для которых давно опубликованы эксплойты.	Атака не требует квалификации: уязвимость известна, инструмент лежит в открытом доступе.
Ошибки конфигурации	Открытая тестовая страница, доступная снаружи админка, включённый режим отладки, дефолтные пароли.	Атакующему не нужно ничего искать — вы сами показали, куда бить.

Сканер, анализ защищённости, пентест: что вам нужно

Эти три слова часто используют как синонимы, хотя разница принципиальная.

Автоматическое сканирование — быстрый поиск известных признаков уязвимостей. Дёшево, полезно как первый слой, но даёт ложные срабатывания и ничего не понимает в вашей бизнес-логике.

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

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

Если приложение проверяют впервые — начинать с пентеста рано. Сначала стоит увидеть картину целиком.

Как проходит аудит в ОБИТ

1. Определяем цель и периметр

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

2. Собираем исходные данные

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

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

3. Проверяем

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

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

4. Оцениваем риск

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

5. Отдаём отчёт и обсуждаем исправления

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

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

Что будет в отчёте

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

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

Отчёт можно передать своей команде, внутренней ИБ-функции или подрядчику, который сопровождает приложение. Если разработчиков не осталось — поможем разобраться, что и в каком порядке чинить.

Три вещи, которые чаще всего портят результат

Проверяют только то, что видно

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

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

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

Не планируют исправления

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

Что делать дальше

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

Мы в ОБИТ проводим аудит информационной безопасности с фокусом на веб-приложения, бизнес-приложения и внутренние сервисы. Согласуем цель и периметр, проверим технические и логические риски, соберём отчёт с приоритетами и дорожной картой — и поможем довести исправления до конца.