📚 Теория: IDOR в сервисах экспорта (раскрыть)
Чем опасен экспорт?
Экспорт чаще всего отдаёт сырые CSV/PDF пачками данных. Без проверки владельца злоумышленник уводит всю историю заказов.
⚠️ Подмена ID даёт прямой доступ к чужим документам.
Как защититься?
Вызывайте сервис с параметрами orderId и customerId, проверяйте роль и соглашение арендатора (tenant).
🔐 Любой ответ должен идти через слой авторизации.
Пользователь вводит чужой ID в URL вида /api/orders/812/export.
Контроллер экспортирует заказ без сверки владельца и выдаёт CSV.
Данные чужих заказов уходят конкуренту, нарушая NDA и 152-ФЗ.
Как нужно: в сервисе экспорта проверяйте связку orderId и currentUser.getCustomerId(), добавьте контроль арендатора и централизованный пермишен EXPORT_ORDER.
Контекст
Команда спешила к релизу и сосредоточилась на генерации файлов, забыв об авторизации. Теперь любой сотрудник с минимальными правами может получить чужие заказы.
- Посмотри, как сервис экспортирует заказ только по
orderId. - Вспомни, какие проверки обычно делает
OrderExportServiceперед выдачей файлов. - Подготовь рекомендации: проверка владельца, разграничение прав, защитные фильтры.
Сниппет
Code Review
Референс-исправление
Проверяйте принадлежность заказа текущему пользователю перед экспортом и валидируйте разрешения.
Флаг ревью: FLAG{java-idor-order-export}
public ResponseEntity<Resource> exportOrder(Long orderId, AppUser currentUser) {
Order order = orderService.requireOwnedOrder(orderId, currentUser.getCustomerId());
accessManager.check(currentUser, Permissions.EXPORT_ORDER, order);
Resource csv = exportService.renderCsv(order);
return ResponseEntity.ok().header(DISPOSITION, buildName(orderId)).body(csv);
}Используйте слой авторизации, валидируйте арендатора, журналируйте отказанные попытки и добавьте интеграционные тесты на IDOR.
Проверка флага
После ревью зафиксируй флаг, чтобы дашборд засчитал лабораторию.