old code /Инженерный разбор · пример отчёта
Демонстрационный примерАудит безопасности

Ваши заказы.
Кто их видит?

Разбор доступа к заказам: что обнаружено, почему это важно и с чего начать исправление.

Объект проверки
Учебный интернет-магазин
Участок
Просмотр одного заказа
Версия примера
DEMO / 01

Все данные и результаты ниже вымышлены и показывают формат отчёта. Это не аудит реального проекта и не выполненный прогон тестов.

Приоритет: закрыть доступ к чужим заказам

В учебном сценарии покупатель может прочитать чужой заказ.

Система проверяет, что пользователь вошёл в аккаунт, но не проверяет, принадлежит ли ему запрошенный заказ. Подмена номера заказа открывает данные другого покупателя.

Первое решение

Добавить проверку владельца на сервере и закрепить её тестами. Для устранения этой проблемы полная переделка системы не требуется.

Посмотреть основание вывода
Один подтверждённый дефект в примере

Статус относится к учебному сценарию. Его основание раскрыто ниже.

Вывод ограничен одним маршрутом

Он не описывает безопасность всего магазина. Остальные участки не исследованы.

02 / Схема доступа

Вход выполнен.
Права не проверены.

Знать пользователя и разрешить ему конкретное действие — две разные проверки.

Как возникает проблемаУчебная схема · до исправления

Нужная граница: перед выдачей данных сервер проверяет право текущего пользователя на этот заказ.

03 / Что обнаружили

От вывода — к доказательству.

SEC–01Высокая важностьПодтверждено в примере

Чтение заказа без проверки владельца

Маршрут GET /api/orders/:id выдаёт заказ по его номеру любому вошедшему покупателю. Проверка принадлежности заказа отсутствует в этом учебном сценарии.

Почему это важно

Другому покупателю становятся доступны состав заказа, имя получателя и адрес доставки. Чужие данные покидают границы аккаунта.

Когда возникает

Покупатель вошёл в аккаунт и передал номер чужого заказа. Изменение или удаление заказа этим примером не подтверждены.

Основание вывода и сценарий воспроизведения

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

  1. Создать тестовых покупателей А и Б с разными аккаунтами.
  2. Создать заказ № 1042 от покупателя А.
  3. От имени покупателя Б запросить этот заказ через API.
  4. Сопоставить владельца заказа и пользователя, получившего ответ.
Иллюстрация запроса и ответа · вымышленные данные
GET /api/orders/1042
User context: buyer_b

HTTP 200 OK
{
  "id": 1042,
  "customerId": "buyer_a",
  "items": ["Учебный товар"],
  "recipient": "Тестовый получатель А",
  "deliveryAddress": "Учебный адрес А"
}

Ожидается: отказ в доступе без данных чужого заказа. В примере: успешный ответ с данными покупателя А. Совпадения номера заказа недостаточно для разрешения доступа.

Как проверить исправление
Критерии будущей приёмки. Проверки исправления ещё не выполнены.
СценарийДо исправления в примереКритерий приёмки
А запрашивает свой заказДоступ естьДоступ сохраняется
Б запрашивает заказ АЧужие данные выданыОтказ, данные не выданы
Запрос без входаДоступ закрытОтказ сохраняется
Запрошен несуществующий заказНе провереноСогласованный ответ без лишних сведений

Конкретные коды отказа фиксируются в контракте API до изменения. Отдельно проверяется, что ответ не раскрывает существование чужого заказа.

Что уже работает в примере

Вход в аккаунт проверяется. Владелец читает свой заказ. Эти сценарии сохраняем при исправлении.

Что осталось неизвестным

Доступ сотрудников, выгрузки и изменение заказов не проверялись. Отсутствие выводов по ним не означает отсутствие проблем.

04 / Следующий шаг

Исправить один участок.
Проверить результат.

Рекомендованный объём первого этапа — доступ покупателя к одному заказу. Другие изменения согласуются отдельно.

  1. Зафиксировать правила доступа

    Кто имеет право читать заказ, что получает посторонний пользователь и какой ответ ожидается для отсутствующего заказа.

    Результат: согласованные правила и проверочные сценарии.

  2. Добавить проверку на сервере

    Связать выдачу заказа с правами текущего пользователя. Проверка только в интерфейсе не закрывает прямой запрос к API.

    Результат: изменение кода и тесты в репозитории клиента.

  3. Проверить и передать

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

    Результат: результаты проверок, описание изменения и порядок выпуска.

Этап завершён, когда результат проверяем.

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

05 / Границы проверки

Что этот отчёт говорит.
И чего не утверждает.

Вопрос
Может ли один покупатель прочитать заказ другого?
Материалы
Вымышленный сценарий DEMO / 01. Реальный код и данные клиентов не использовались. В рабочем отчёте указываются версия кода, дата и предоставленные материалы.
Граница примера
Чтение одного заказа через GET /api/orders/:id, роли: владелец, другой покупатель, посетитель без входа.
За пределами
Оплата, изменение заказов, права сотрудников, инфраструктура, зависимости и нагрузка. Это не заключение о безопасности магазина в целом.
Степень уверенности
«Подтверждено в примере» обозначает заданный результат учебного сценария. «Не проверено» обозначает отсутствие вывода. Реальные проверки в этом демо не проводились.

Результат принадлежит вам

Понятный следующий шаг.
Свободный выбор исполнителя.

После бесплатного аудита отчёт остаётся у вас. Используйте его со своей командой, передайте другому исполнителю или обсудите следующий этап с Old Code.

До начала

Согласуем один вопрос, границы, материалы и дату выдачи. Условия передачи кода и обработки с AI обсуждаем заранее.

Если продолжаете

Определяем результат, стоимость и приёмку небольшого этапа. Исправления не входят в бесплатный аудит.

Если останавливаетесь

Следующий этап не начинается без согласия. Условия остановки внутри этапа фиксируются до его начала.