Пентест веб-приложения с 200+ API-эндпоинтами: как ITG Security проверил защищённость разработчиков ПО

О Клиенте

Российская IT-компания, специализирующаяся на разработке программного обеспечения.

Особенности реализации

• Большой объем API - В рамках тестирования требовалось проверить веб-приложение с обширным API — более 200 эндпоинтов. — Это потребовало детального покрытия различных типов запросов, пользовательских сценариев, ролей и механизмов обработки данных, чтобы не ограничиваться выборочной проверкой отдельных функций.
• Связь веб-приложения с физической инфраструктурой — Проверяемое решение используется не только как обычный веб-сервис, но и как часть системы управления цифровыми экранами. Поэтому тестирование требовало аккуратного подхода, важно было выявить уязвимости, не создавая риска некорректной работы устройств, отображающих контент.
• Разветвленная система ролей — В приложении была реализована сложная ролевая модель. Для тестирования это означало необходимость проверять не только технические уязвимости, но и корректность разграничения доступа: какие действия доступны разным типам пользователей, можно ли обойти ограничения роли, получить доступ к чужим данным или выполнить операции с повышенными привилегиями.
• Проверка бизнес-логики, а не только технических уязвимостей — Из-за большого количества API-методов и сложной ролевой модели особое внимание уделялось сценариям нарушения бизнес-логики: подмене идентификаторов, доступу к объектам других пользователей, некорректной обработке прав и возможности выполнения действий вне разрешенного пользовательского сценария

Решение

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

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

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

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

Результаты

• Заказчик получил объективную картину защищенности веб-приложения — По итогам тестирования клиент получил подтвержденное понимание того, какие компоненты приложения, API-методы и пользовательские сценарии могут создавать риски для безопасности, а какие механизмы защиты работают корректно.
• Были проверены реальные сценарии эксплуатации уязвимостей — Проект показал не только отдельные технические недостатки, но и возможные цепочки атаки: от доступа с правами обычного пользователя к попыткам обхода ролевых ограничений, обращению к чужим объектам, получению чувствительных данных или выполнению действий, не предусмотренных текущей ролью.
• Оценена корректность ролевой модели и разграничения доступа — С учетом разветвленной системы ролей заказчик получил понимание, насколько надежно приложение разделяет полномочия пользователей, защищает данные разных клиентов и ограничивает доступ к административным функциям через веб-интерфейс и прямые API-запросы.
• Проверена безопасность большого API — Более 200 эндпоинтов были проанализированы на предмет типовых веб-рисков, ошибок авторизации, небезопасной обработки параметров, раскрытия служебной информации и некорректной бизнес-логики. Это позволило выявить приоритетные зоны для доработки и снизить риск появления уязвимостей в критичных пользовательских сценариях.
• Заказчик получил приоритизированные рекомендации по устранению рисков — Все выявленные недостатки были описаны с учетом их потенциального влияния на бизнес и техническую архитектуру приложения. Клиент получил не просто перечень уязвимостей, а понятный план действий: какие проблемы требуют срочного исправления, какие можно закрывать в плановом порядке и какие меры помогут повысить общий уровень защищенности приложения.

Выводы для заказчиков

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

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

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

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