Аудит защищённости
Отвечает на вопрос, что в приложении можно проэксплуатировать. Он находит причину — уязвимость в коде, логике или конфигурации, — которую затем можно устранить в самом приложении.
Находит причину — в коде и логике
Аудит ИБ
Аудит защищённости веб-приложений
Проверяем сайт, портал, личный кабинет, интернет-магазин, API и backend мобильных приложений с позиции внешнего или авторизованного атакующего: ищем уязвимости, подтверждаем их реализуемость и показываем, к чему приводит каждая. На выходе — отчёт, по которому разработчики понимают, что и как чинить.
Ошибка в авторизации, API или бизнес-логике даёт доступ к чужим заказам, персональным данным, личным кабинетам или административным функциям. Мы находим такие сценарии до того, как ими воспользуются. Веб-приложение доступно из интернета круглосуточно и атакуется автоматически — это чаще всего первое, что проверяет злоумышленник.
Когда обращаются
Когда нужен аудит веб-приложения
- Запускаете новый сайт, портал, личный кабинет или мобильное приложение с бэкендом
- Выкатили крупное обновление и хотите убедиться, что не открыли новых дыр
- Приложение обрабатывает персональные данные, платежи или чувствительную информацию
- Заказчик, банк-эквайер или партнёр требует подтвердить защищённость
- Был инцидент или подозрительная активность, и нужно понять, через что могли войти
- Приложение писал подрядчик, и хочется независимо проверить результат
- Готовитесь к внедрению WAF и хотите понять, что именно он должен закрывать
- Нужна регулярная проверка перед каждым релизом
Кому особенно актуально
Интернет-магазинам и e-commerce
Личным кабинетам клиентов
Порталам с персональными данными
SaaS и B2B-платформам
Мобильным приложениям с API
Компаниям, принимающим приложение от подрядчика
Организациям перед внедрением WAF
Частая путаница
Аудит и WAF — это найти и закрыть, а не одно и то же
Их часто ставят как альтернативу: «поставим WAF — и аудит не нужен». Это неверно, потому что они делают разное.
WAF
Отвечает на вопрос, как остановить атаку на входе. Он закрывает симптом — блокирует вредоносные запросы, не трогая уязвимость внутри.
Закрывает симптом — на входе
Классы угроз
Что мы ищем
Проверяем приложение по направлениям, соответствующим современным классам веб-угроз. Ниже — основное.
Инъекции
SQL Injection и другие внедрения, ведущие к доступу к базе данных и выполнению команд.
Межсайтовый скриптинг (XSS)
Внедрение скриптов, атакующих пользователей приложения.
Обход аутентификации и авторизации
Доступ к чужим данным и функциям, повышение привилегий, работа под чужой учётной записью.
Ошибки бизнес-логики
То, что не ловится сканером: манипуляции с ценой, скидками, бонусами, порядком шагов, чужими заказами.
Небезопасные прямые ссылки на объекты
Доступ к чужим записям простым перебором идентификаторов.
CSRF
Выполнение критичных операций от имени пользователя без его намерения, если приложение не защищает такие действия.
SSRF и обращения к внутренним ресурсам
Использование серверной части приложения для доступа к внутренним сервисам, метаданным облака и закрытым адресам.
Загрузка и выполнение произвольного кода
Попытки загрузить вредоносный файл и добиться его исполнения на сервере.
Уязвимости API
Недостаточная проверка прав, отсутствие ограничения частоты запросов, избыточная выдача данных, массовое извлечение записей через API, обход прав между объектами.
Ошибки конфигурации
Открытые служебные интерфейсы, отладочные режимы, небезопасные заголовки, раскрытие технической информации.
Уязвимости компонентов и зависимостей
Известные уязвимости в используемых библиотеках и фреймворках.
Проблемы сессий и хранения данных
Предсказуемые токены, некорректное завершение сессий, небезопасное хранение.
Глубина проверки
Форматы проверки
Способ доступа к приложению выбирается под задачу и влияет на глубину.
Чёрный ящик
Проверяем приложение снаружи, без исходного кода и учётных записей — как внешний атакующий. Показывает, что реально доступно злоумышленнику без каких-либо привилегий.
Серый ящик
Даёте тестовые учётные записи разных ролей — пользователь, менеджер, администратор, партнёр, оператор. Позволяет проверить разграничение доступа между ролями, работу под привилегированным пользователем и логику, доступную только после входа. Оптимальный баланс глубины и трудозатрат.
Белый ящик
Добавляется доступ к исходному коду и архитектуре. Максимальная глубина: находятся уязвимости, до которых снаружи не добраться, и подтверждается первопричина в коде.
Подготовка
Что нужно для старта работ
URL приложения и описание, что оно делает и какие данные обрабатывает
Границы проверки: какие домены, разделы, API входят в объём, а какие трогать нельзя
Среда проверки: тестовая или боевая, согласованное окно работ
Тестовые учётные записи разных ролей — для формата серого ящика
Исходный код и архитектурная документация — для полноценного белого ящика
Контакты технических специалистов на вашей стороне для оперативных уточнений
Письменное разрешение на проведение работ по указанным ресурсам
Этапы проекта
Как проходит аудит
Согласуем границы и правила
Фиксируем объём проверки, среду, окно работ, формат доступа и что тестировать нельзя. Оформляем разрешение на работы.
Изучаем приложение
Разбираемся, как устроено приложение, какие роли и функции есть, где обрабатываются данные, где точки входа и API.
Проводим проверку
Автоматизированный анализ в сочетании с ручной проверкой. Найденные уязвимости подтверждаем — доводим до демонстрации того, что их можно реально использовать, не нанося ущерба.
Оцениваем и приоритизируем
Каждой уязвимости присваиваем уровень риска с учётом того, что она даёт атакующему и насколько просто её проэксплуатировать. Отделяем критичное от косметического.
Готовим отчёт
Описываем каждую находку: где, в чём суть, как воспроизвести, к чему приводит, как исправить. Отдельно — краткая выжимка для руководства.
Разбираем результаты
Проходим отчёт с вашей командой, отвечаем на вопросы разработчиков, помогаем расставить приоритеты в исправлении.
Проверяем исправления
После устранения проводим повторную проверку закрытых уязвимостей и подтверждаем, что они действительно закрыты, а не спрятаны.
Результат
Что вы получаете
01
Перечень найденных уязвимостей с уровнем риска по каждой
02
По каждой уязвимости: расположение, описание, шаги воспроизведения, возможные последствия, подтверждение реализуемости
03
Конкретные рекомендации по устранению — на языке разработчика, а не общими словами
04
Разделение находок на критичные, требующие немедленного исправления, и второстепенные
05
Выжимку для руководства: общий уровень защищённости и главные риски без технических деталей
06
При формате белого ящика — указание первопричины в коде, а не только внешнего проявления
07
Повторную проверку исправлений и подтверждение закрытия
08
Рекомендации, что имеет смысл закрыть на уровне WAF, если критичное нельзя быстро исправить в коде
Стандарты
На что опираемся
OWASP Top 10 и OWASP ASVSкак основа перечня проверок и уровней требований
OWASP API Security Top 10для проверки API, с адаптацией под архитектуру конкретного приложения
Методические документы ФСТЭК Россиипо анализу уязвимостей и оценке угроз — в части, применимой к защищаемым системам
Требования заказчика, регуляторов и платёжных партнёровесли проверка проводится для подтверждения соответствия
Сроки
Сроки и стоимость
Срок и стоимость зависят от размера и сложности приложения, а не от отрасли. На объём влияет:
Размер приложения: число функций, ролей, форм, точек входа
Наличие и объём API
Формат проверки: чёрный, серый или белый ящик
Среда: тестовая или боевая с ограничениями
Нужна ли повторная проверка после исправлений (рекомендуем — включаем по умолчанию)
Почему мы
Почему IST
- 15 лет на рынке информационной безопасности
- 2 000+ реализованных проектов
- Офисы в Самаре, Оренбурге, Нижнем Новгороде и Москве
- Лицензии ФСТЭК и ФСБ
- Проверяли и защищали публичные веб-приложения в разных отраслях: порталы, личные кабинеты, интернет-магазины, отраслевые сервисы
- Каждую уязвимость подтверждаем, а не просто отмечаем сработавший сканер: отчёт не содержит находок, которые невозможно воспроизвести
- Делаем и аудит, и защиту: после проверки можем закрыть найденное — в коде, на уровне WAF или в инфраструктуре
- Проводим повторную проверку исправлений, а не оставляем заказчика гадать, закрыта ли уязвимость
Вопросы
Частые вопросы
Чем ваш аудит отличается от автоматического сканирования?
Сканер находит типовые признаки уязвимостей и выдаёт список срабатываний, часть которых ложные. Аудит подтверждает реализуемость каждой находки, проверяет авторизацию между ролями, бизнес-логику и цепочки действий, оценивает последствия для данных и процессов. Сканер — это инструмент внутри аудита, а не аудит.
Чем аудит веб-приложения отличается от теста на проникновение?
Аудит веб-приложения сосредоточен на самом приложении: его функциях, логике, API. Тест на проникновение обычно шире и проверяет инфраструктуру целиком — сеть, серверы, периметр. Часто они дополняют друг друга: аудит приложения плюс пентест инфраструктуры дают полную картину.
Можно ли проверять на боевой среде?
Да, но с осторожностью: в согласованное окно, с мерами предосторожности и без нагрузочных сценариев, способных нарушить работу. Где возможно, надёжнее и удобнее тестовая среда, идентичная боевой.
Вы не сломаете приложение в процессе?
Подтверждение уязвимостей мы доводим до демонстрации возможности эксплуатации, но не до нанесения ущерба: не портим данные, не выводим сервис из строя. Правила и границы фиксируем письменно до начала работ.
Мы поставили WAF. Аудит всё равно нужен?
Да. WAF блокирует часть атак на входе, но не устраняет уязвимость в коде и не ловит ошибки бизнес-логики. Аудит показывает, что именно уязвимо, и что WAF должен закрывать в первую очередь.
Что делать с отчётом, если у нас нет своих разработчиков?
Рекомендации написаны так, чтобы их мог выполнить любой технический подрядчик. Если приложение делали не вы, отчёт — основание предъявить исправления разработчику. При необходимости поможем с устранением сами.
Как часто проводить аудит?
Как минимум перед крупными релизами и после существенных изменений. Для активно развивающихся приложений разумна регулярная проверка, встроенная в процесс выпуска.
Начать проект
Проверить защищённость приложения
Расскажите о приложении — что это, какие данные обрабатывает, есть ли API, тестовая среда и разрешение на проверку. Назовём формат, срок и стоимость.