Bug2Lab — IDOR: доступ к чужому объекту по чужому ID

IDOR: доступ к чужому объекту по чужому ID

Пользователь меняет числовой идентификатор в URL и получает чужие данные. Приложение не проверяет «а это вообще его ресурс?» — только то, что ресурс существует. Фикс — проверять владение.

Как выглядит атака

Клиент с токеном пользователя А делает:
GET /api/order/98273
потом просто меняет ID:
/api/order/98274
и видит заказ другого клиента.

GET /api/order/98274
200 OK (application/json)

{
"orderId":98274,
"email":"vip.customer@corp.example",
"total":"12999.00",
"cardLast4":"7742"
}

Почему это стало возможным

Контроллер получает orderId и возвращает заказ без проверки, принадлежит ли он текущему пользователю.

Проблемный код
@GetMapping("/api/order/{id}")
public OrderDto getOrder(@PathVariable Long id) {
    return orderService.findById(id); // ❌ нет проверки владельца
}

Как это чинится правильно

Вместо «дай заказ по ID» нужно «дай заказ этого пользователя по ID». То есть проверка владения ресурса.

Исправленный паттерн
@GetMapping("/api/order/{id}")
public OrderDto getOrder(@PathVariable Long id, Principal principal) {
    String username = principal.getName();
    return orderService.findByIdAndUsername(id, username); // ✅ проверка владельца
}

bug2regressРегрессионный тест

Тест использует токен обычного пользователя и пытается прочитать заказ, принадлежащий другому пользователю. Ожидаем 403 / 404. Если 200 — билд стопаем.

#!/bin/bash # idor-check.sh TOKEN_USER_A="Bearer userA-token" FOREIGN_ORDER_ID=98274 STATUS=$(curl -s -o /tmp/order.json -w "%{http_code}" \ -H "Authorization: $TOKEN_USER_A" \ "https://staging.example.internal/api/order/$FOREIGN_ORDER_ID") if [ "$STATUS" = "200" ]; then echo "[BLOCK] IDOR: пользователь читает чужой заказ ($FOREIGN_ORDER_ID)" exit 1 fi echo "[OK] Чужие объекты недоступны (HTTP $STATUS)" exit 0

Это защищает личные данные клиентов и финансовую информацию.

Проверка пониманияЧто было не так?

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

Был отключён TLS.

Фикс — искать заказ по (id, username), а не только по id.

Ошибка заключалась в том, что база данных не работала.

Стандарт:доступ к объекту = проверка владения. Любой ресурс «по ID» обязан быть «по ID + текущий пользователь».

Теория (по желанию) IDOR = «а я могу посмотреть чужой заказ? да, могу»

🔍1. Что такое IDOR?

Insecure Direct Object Reference — когда пользователь может обратиться к объекту напрямую по его ID и получить доступ, даже если это не его объект. Типичный пример: меняешь /api/order/123 на /api/order/124 и видишь чужие данные.

💳2. Почему бизнесу это больно?

Доступ к чужим суммам, скидкам, VIP-статусу, картам лояльности.
Утечка персональных данных конкретных клиентов (PII).
Репутационный удар: «через личный кабинет я увидел заказы другого клиента».

Это один из самых унизительных публичных постов: «я просто изменил цифру в URL — и получил чужой чек».

🧪3. Почему так случается в коде?

Сервис писали быстро → «ну дай заказ по ID».
Думали «это же внутренняя API, сверху API-шлюз всё проверит» — а потом этот метод внезапно оказалась прямым публичным эндпоинтом.
Никто не задал вопрос: «А если я подставлю чужой ID?»

📏4. Новый стандарт

Методы вида findById(id) в сервисах для пользовательских данных запрещены.
Должно быть findByIdAndUsername(id, username) или findByIdOwnedByCurrentUser(...).
Если нельзя показать ресурс — вернуть 403 / 404, но не данные.

Это становится требованием кода и ревью, не «рекомендацией безопасности».

🚦5. Зачем регресс в пайплайне?

Потому что даже если вы сегодня поправили /api/order/{id}, завтра появится /api/invoices/{id}, и новый разработчик повторит ту же ошибку. Регресс-тест просто пытается прочитать «чужой ресурс» тестовым токеном и валит билд, если получилось. Это техконтроль, а не надежда «никто не забудет».

✅6. Что можно честно сказать руководству

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

Это то, что снижает репутационный риск повторно всплыть в прессу как «любой видел чеки VIP-клиентов».

bug2regressРегрессионный тест

Проверка пониманияЧто было не так?

Теория (по желанию) IDOR = «а я могу посмотреть чужой заказ? да, могу» раскрыть

Теория (по желанию) IDOR = «а я могу посмотреть чужой заказ? да, могу»