На примере опубликованного кейса Sentra разбираем границы доказательства: служебный токен, исторические заказы, рабочая система, контрольная копия и повторная проверка.
В отчёте о проверке API важна не только формулировка «нарушение авторизации». Команде, которая будет исправлять проблему, нужны исходная роль, действие, объект и наблюдаемый результат. Без них предположение об уязвимости легко принять за доказательство более широкого доступа.
Это методический разбор уже опубликованного кейса ритейлера, а не новая проверка заказчика. Новые клиентские данные здесь не раскрываются. Названия маршрутов и численные показатели исходного кейса изменены для анонимизации; они не используются как статистика эффективности продукта.
Служебный токен может подтверждать, что запрос выполняет известное устройство. Из этого не следует право читать любой заказ покупателя. Серверу нужно проверить допустимость конкретного действия с конкретным объектом для вызывающей стороны.
Такой класс ошибок описан в OWASP API1:2023 — Broken Object Level Authorization. Проверку принадлежности и полномочий нужно выполнять на сервере для операций с объектом; наличие авторизации на самом маршруте её не заменяет.
В сервисе исторических заказов принимался токен устройства, а принадлежность заказа не проверялась. Запросы вернули карточки чужих заказов с данными покупателей. Это наблюдаемый доступ к объектам, а не вывод только из успешного HTTP-статуса.
На завершённых заказах прошлых лет, с согласия заказчика, отдельно проверили отмену и изменение способа оплаты. Сервис подтвердил операции и вернул платёжную ссылку. Саму оплату не выполняли. Доступ к текущим заказам новой системы не подтвердился.
Из такого результата можно сделать узкий вывод о проверенном историческом сервисе и выполненных операциях. Нельзя сообщать, что проверка доказала произвольный доступ ко всем заказам, реальное списание денег или обход авторизации во всех приложениях компании.
В другой цепочке того же кейса запись файлов подтвердили на рабочем сервисе видеоконференций. Дальнейший путь до выполнения команд и использования ключа подписи токенов воспроизвели в контрольной копии среды.
Эти результаты имеют разные границы. Наличие технического пути в копии важно для оценки риска, но не доказывает, что все его шаги выполнили на рабочей системе. В итоговом отчёте среду следует указывать рядом с каждым существенным результатом.
Для каждой находки зафиксируйте:
Не нужно расширять объём проверки только ради более впечатляющего отчёта. Для изменения данных заранее определяют подходящие объекты и разрешённые операции.
Для ошибки доступа к объекту направление исправления — серверная проверка полномочий вызывающей стороны на нужную операцию. Скрытый элемент интерфейса и трудно угадываемый идентификатор не заменяют такую проверку.
При ретесте полезно повторить исходный отрицательный сценарий и проверить, что разрешённое действие легитимного пользователя продолжает работать. Если нет прежнего доступа, тестового объекта или сопоставимой версии, результат ретеста следует обозначить как ограниченный, а не как доказанное устранение.
Это рекомендации по проверке исправления. Новый ретест клиентской системы в рамках подготовки этой статьи не проводился; его результат здесь не заявляется.
На пилоте оценивайте воспроизводимость, ясность границ и полезность следующего шага. Количество находок само по себе не показывает качество проверки. Попросите продемонстрировать, как в результате различаются гипотеза, подтверждённое наблюдение и непроверенный участок.
Обсудить проверку вашей системы можно через форму заявки. Вопросы к материалу можно направить команде Sentra.
