Иногда загрузка изображений выглядит безопасной: проверяется расширение, MIME type, magic bytes и файл сохраняется как
image/png.Но баг может быть не в загрузке, а в выдаче файла. Если приложение хранит пользовательские изображения в S3/MinIO и отдаёт их через reverse proxy, стоит проверить публичный объект с параметром:
?response-content-type=text/html
Пример:
https://cdn.target.com/uploads/avatar.png?response-content-type=text/html
Если в ответе видишь:
Content-Type: text/html
это сигнал для дальнейшего ресёрча. Браузер может начать обрабатывать загруженный файл не как картинку, а как HTML.
📌 Для MinIO такой override может сработать сразу: был объект с
image/png, добавил параметр — получил text/html.📌 Для S3 анонимный запрос обычно отвечает ошибкой:
Request specific response headers cannot be used for anonymous GET requests
Но это не тупик, а признак, что override поддерживается, просто S3 не применяет его для анонимного GET-запроса. В райтапе багхантер показал байпас: подписываешь запрос своим AWS-аккаунтом и добавляешь
response-content-type=text/html уже в signed URL.Главное — проверяй
origin. Если пэйлоад открывается на случайном storage-домене, импакт может быть низким. Если файл отдаётся с целевого домена:cdn.target.com/uploads/file.png
target.com/uploads/file.png
то HTML выполняется уже в контексте доверенного
origin. Чек-лист для багхантера ➡️
✅ Добавляй
?response-content-type=text/html к каждому публичному загруженному изображению✅ Смотри, меняется ли
Content-Type✅ Отдельно проверяй поведение MinIO и S3
✅ Оценивай не только рендер, но и
origin