Когда доступ к файлам «защищён» сложными идентификаторами, это почти всегда означает одно: уязвимость не исправили, а спрятали под ковёр. Кейс из райтапа хорошо показывает, как такие баги выходят наружу ⤵️
Если ты нашёл классическую IDOR — с одного аккаунта можешь получить доступ к файлам другого —
GET /api/v1/files/view/{file_id} HTTP/2
Host: api.example.com
Authorization: Bearer <ACCOUNT_B_JWT>но
file_id имеет сложный формат:[UserID]_[Filename]_[Timestamp]_[UniqueID]
→ IDOR есть, но как получить другие идентификаторы?
1️⃣ Найди эндпоинты, куда клиент передаёт имя файла:
Подходящие параметры:
*
document_key*
file_key*
object_key* blob_name
Такие точки входа обычно встречаются в загрузке, обновлении статуса и регистрации документов.
2️⃣ Попробуй отправить пустой ключ
Частая ошибка бекенда — передавать значение в storage/SDK как есть.
document_key: ""
document_key: " "
document_key: "%20"
document_key: null
S3-совместимые хранилища интерпретируют пустой ключ как
ListBucket и возвращают список файлов.3️⃣ Если получил список — используй пагинацию
S3 и аналоги отдают:
* первые 1000 файлов
* флаг
IsTruncated: true* последний ключ, который можно использовать как
?marker=...Так можно пройти весь бакет и собрать имена файлов 💭
4️⃣ Подставь полученный ключ в «легитимный» эндпоинт
Если есть эндпоинт, который:
* принимает
document_key* возвращает
pre-signed URL или прямой доступ— подставь туда любой найденный ключ.
Если сервер не проверяет владельца файла, он подпишет URL к чужому объекту. Это и есть полноценный IDOR 💡