Обход авторизации и чужие данные
Смена идентификатора в запросе отдаёт чужой заказ, документ или профиль: проверка прав сделана только в интерфейсе, но не на сервере.
Выберите тему — соберём контекст
Проверяем приложение так, как это делает реальный злоумышленник: обходим авторизацию, подменяем параметры, ломаем бизнес-логику. По каждому шагу — воспроизводимый сценарий и рекомендация по исправлению.
Или сразу: +7 (962) 368-39-51 Telegram
Типовые классы уязвимостей в проектах, которые мы тестировали: от интернет-магазинов до корпоративных кабинетов.
Смена идентификатора в запросе отдаёт чужой заказ, документ или профиль: проверка прав сделана только в интерфейсе, но не на сервере.
Цену, количество или скидку можно изменить на стороне клиента, а сервер доверяет переданному значению — заказ оформляется дешевле.
Эндпоинты отдают больше полей, чем нужно интерфейсу: внутренние идентификаторы, хеши, стоимость закупки, персональные данные без ограничения выборки.
Проверка типа файла обходится подменой заголовка, а серверные запросы по URL пользователя открывают доступ к внутренней сети.
Перебор пароля без ограничений, отсутствие второго фактора, предсказуемые ссылки на сброс пароля и восстановление доступа.
Устаревшие пакеты и фреймворки содержат опубликованные уязвимости, которые эксплуатируются автоматическими сканерами в первые дни после раскрытия.
Объём согласуем до начала работ: можно взять только внешний периметр или весь продукт целиком.
Проверяем то, что доступно из интернета: сайт, личный кабинет, API, панели администрирования, открытые сервисы.
Ручной разбор сценариев использования: регистрация, вход, оплата, личный кабинет, загрузка файлов, поиск и фильтры.
Отдельно проверяем REST и webhooks: именно через них чаще всего утекают данные между системами.
Передаём результат в формате, с которым можно работать: разработчику — шаги воспроизведения, руководителю — риски и приоритеты.
Работаем на согласованном периметре, в оговорённые окна и с фиксацией всех действий.
Фиксируем периметр, окна проведения, тестовые аккаунты и запрещённые действия. Подписываем соглашение о конфиденциальности.
Собираем карту приложения, точки входа и роли. Изучаем логику: что и кому разрешено делать.
Подтверждаем находки реальной эксплуатацией с минимально необходимым воздействием. Критичное сообщаем сразу, не дожидаясь отчёта.
Передаём отчёт, разбираем его с командой, сопровождаем исправления и проверяем фиксы повторно.
Сканер сравнивает версии библиотек и заголовки ответов с базой известных сигнатур. Это полезно, но находит только то, что уже описано. Пентест — это ручная работа человека, который пытается достичь цели: получить доступ к чужому заказу, изменить сумму платежа, выгрузить базу клиентов.
Поэтому в наших отчётах основную ценность несут находки в бизнес-логике и контроле доступа: их не видит ни один автоматический инструмент, и именно они чаще всего приводят к реальным утечкам.
До начала работ нам нужен согласованный периметр и тестовые учётные записи для каждой роли: гость, клиент, менеджер, администратор. Если есть тестовый стенд, максимально похожий на продакшн, — это лучший вариант: тестирование пройдёт без риска для реальных данных.
Если тестового контура нет, работаем на проде в согласованные окна и с ограничениями: не удаляем данные, не выводим систему из строя, не рассылаем письма реальным пользователям. Для критичных операций заранее договариваемся о способе подтверждения.
Разумный минимум — один раз в год, а также перед каждым значимым релизом: новая платёжная интеграция, новый личный кабинет, подключение внешнего API меняют поверхность атаки. Если у вас непрерывные релизы, эффективнее сочетать ежегодный пентест с регулярным сканированием и разбором изменений в критичных сценариях.
Для проектов, где требуется соответствие PCI DSS или ISO 27001, периодичность задаётся требованиями стандарта: как правило, не реже одного раза в год и после существенных изменений инфраструктуры.
Мы работаем с минимально необходимым воздействием и заранее согласуем запрещённые действия. Опасные проверки, способные повлиять на доступность, выполняются только после отдельного подтверждения и в согласованное окно. По статистике наших проектов воздействие на продакшн ограничивается тестовыми записями, которые мы затем удаляем.
Средний срок для личного кабинета или интернет-магазина — от одной до трёх недель в зависимости от размера функциональности и количества ролей. Простой сайт-визитка проверяется за 2–4 дня, крупная платформа с API и мобильным приложением — от месяца.
Желательно, но не обязательно. Стенд снижает риски и позволяет проверять разрушительные сценарии. При его отсутствии работаем на продакшене в согласованные окна, исключая операции, которые могут повредить данные или пользователям.
Исправить находки в порядке приоритета, начиная с критичных. Мы разбираем отчёт с вашей командой, при необходимости помогаем с исправлениями и после фиксов бесплатно проверяем, что уязвимость действительно закрыта.
Смежные задачи, которые обычно решаются в одном проекте с этой.
Опишите периметр и сроки — предложим объём работ и назовём стоимость.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.