Начинаем в багбаунти: 10 неочевидных уязвимостей S3-интеграций в веб-приложениях
Объектное хранилище S3 давно стало стандартным компонентом веб-систем. Его используют для размещения пользовательских файлов, изображений, резервных копий, статических ресурсов и документов. Однако разработчики нередко воспринимают S3 как обычную папку в облаке, не учитывая особенности протокола, модели разрешений и поведения прокси-серверов. В результате появляются уязвимости, которые не всегда обнаруживаются при поверхностной проверке.
В этом материале разберём типовые и менее очевидные проблемы, встречающиеся при интеграции S3 с веб-приложениями. Практический подход к теме, включая лабораторные стенды и разбор цепочек атак, представлен в статье о том, как находить уязвимости S3-интеграций в веб-приложениях. Все описанные сценарии следует рассматривать только в рамках разрешённых тестов, собственных стендов и программ bug bounty.
Что такое S3 и почему он становится источником проблем
S3 - объектное хранилище, первоначально созданное Amazon. Со временем S3 превратился не только в название сервиса AWS, но и в фактический стандарт API, который поддерживают многие облачные платформы и совместимые решения.
Основные операции выполняются через HTTP-запросы:
- `PUT` используется для загрузки или изменения объекта;
- `GET` - для получения файла или списка объектов;
- `DELETE` - для удаления;
- запрос `GET` к корню бакета может возвращать его содержимое.
Сам по себе протокол не является небезопасным. Риски возникают на стыке нескольких компонентов: настроек доступа, логики приложения, прокси, CDN и механизмов подписи запросов.
Для авторизованной работы применяются Access Key и Secret Key. На их основе формируется криптографическая подпись запроса. В старом варианте Signature v2 в неё входят HTTP-метод, дата, тип содержимого и другие параметры запроса. Затем вычисляется HMAC-SHA1, а результат кодируется в Base64. Более современная схема Signature v4 сложнее и учитывает регион, сервис и временные параметры.
Для временного доступа к объектам используются presigned URL - подписанные адреса с ограниченным сроком действия. Если такая ссылка утекла в логи, историю браузера, аналитические системы или сторонние сервисы, доступ к файлу может сохраниться до окончания срока действия.
Два варианта подключения хранилища
На практике встречаются два основных подхода.
Первый - непосредственное обращение к S3-клиенту из серверного кода приложения. В этом случае приложение само управляет ключами, именами объектов, заголовками и содержимым файлов. Потенциально опасные параметры ограничены тем, что разработчик разрешил передать через клиентскую логику.
Второй - публикация хранилища через reverse proxy, например nginx. Здесь запрос пользователя может почти напрямую попасть в S3. Если прокси лишь добавляет префикс пути и не ограничивает методы, заголовки и query-параметры, наружу становятся доступны многие штатные возможности API.
Именно проксирование часто приводит к появлению неожиданных дефектов. Например, разработчик рассчитывает, что пользователи смогут только скачивать файлы, но фактически через прокси остаются доступны загрузка, удаление, листинг, изменение метаданных и другие операции.
Наиболее распространённые классы уязвимостей
1. Ошибки в ACL и Bucket Policy
S3 поддерживает ACL и политики бакета. Особую опасность представляет неправильное понимание группы `AuthenticatedUsers`. Это не пользователи конкретного проекта или аккаунта, а все аутентифицированные пользователи соответствующей S3-платформы. В публичных облаках такая настройка может фактически открыть данные огромному числу посторонних клиентов.
Нарушения прав доступа способны привести к чтению конфиденциальных документов, замене файлов, удалению объектов или загрузке вредоносного содержимого. Перед публикацией бакета необходимо отдельно проверять права на чтение, запись, удаление и получение списка объектов.
2. Хранимая XSS через загружаемые файлы
Если приложение разрешает загрузку HTML, SVG или других интерпретируемых браузером форматов, злоумышленник может разместить файл с JavaScript. Опасность усиливается, если объект доступен с домена приложения и отдаётся с подходящим `Content-Type`.
Даже при ограничении расширений необходимо проверять фактическое содержимое, корректно задавать `Content-Disposition` и по возможности использовать отдельный домен для пользовательских файлов.
3. Подмена бакета или endpoint
В конфигурации иногда остаются управляемые пользователем параметры: имя бакета, регион, endpoint либо часть пути. Если эти значения не проверяются, приложение может начать работать с чужим хранилищем или отправлять туда внутренние данные.
Подобный сценарий особенно опасен для резервных копий, изображений, экспортов баз данных и файлов, автоматически создаваемых сервером.
4. Обход правил rewrite и proxy_pass
Ошибки nginx-конфигурации способны менять смысл URL при обработке завершающего слеша, кодированных символов, двойных разделителей и относительных путей. В результате запрос может попасть не в предусмотренный каталог или обойти ограничение, которое разработчик считал надёжным.
При аудите важно проверять не только обычные URL, но и разные варианты нормализации пути. Отдельное внимание следует уделять сочетанию `location`, `rewrite`, `alias` и `proxy_pass`.
5. Доступ к служебным операциям S3
Если прокси без фильтрации пропускает HTTP-методы и параметры, пользователь может получить доступ к операциям, которые не предполагались бизнес-логикой. К ним относятся листинг объектов, получение метаданных, загрузка, удаление и изменение заголовков.
Безопасная схема должна явно разрешать только необходимые методы и проверять допустимый формат ключа объекта.
6. Отравление кэша
S3, прокси и CDN могут по-разному учитывать query-параметры, заголовки и путь при формировании ключа кэша. Если ответ для одного варианта запроса сохраняется и затем выдаётся другому пользователю, возникает cache poisoning.
Последствия зависят от содержимого ответа: от подмены статического ресурса до публикации чужого файла или фиксации вредоносных заголовков. Необходимо согласовать правила кэширования между приложением, прокси и CDN.
7. Некорректная обработка Content-Type и Content-Disposition
Метаданные объекта часто задаются при загрузке и затем используются браузером. Ошибочный `Content-Type` может привести к выполнению HTML или SVG, а неправильный `Content-Disposition` - к открытию файла непосредственно в окне браузера вместо безопасного скачивания.
Контент пользовательских файлов следует отдавать с безопасными типами, а для потенциально активных форматов использовать принудительную загрузку и изолированный домен.
8. Предсказуемые имена объектов
Если ключи формируются из идентификаторов пользователя, даты или последовательного номера, файлы можно перебирать. Даже при закрытом листинге злоумышленник способен обнаружить документы по предсказуемым адресам.
Надёжнее использовать криптографически случайные идентификаторы, проверять принадлежность объекта владельцу и не полагаться только на невозможность угадать URL.
9. Утечки подписанных URL
Presigned URL часто попадают в журналы, рефереры, сообщения об ошибках и клиентскую аналитику. Если срок действия слишком велик, временная ссылка превращается в длительный канал доступа.
Срок жизни подписей должен соответствовать задаче, а чувствительные объекты не следует встраивать в страницы, которые могут передавать адрес сторонним доменам.
10. Цепочки из нескольких слабостей
Наиболее серьёзные инциденты возникают не из-за одной ошибки, а из-за их комбинации. Например, доступный через прокси `PUT` позволяет загрузить SVG, неверный `Content-Type` заставляет браузер выполнить сценарий, а широкая политика CORS или общий домен открывают доступ к данным пользователей.
Поэтому пентест AWS S3 должен учитывать не только разрешения самого бакета, но и полный путь запроса: браузер, приложение, reverse proxy, CDN и хранилище.
Как организовать проверку
Для безопасного аудита полезно создать отдельный стенд с тестовым бакетом и минимальными правами. В нём проверяют, какие методы доступны без авторизации, как обрабатываются различные типы файлов, что происходит с нестандартными путями и насколько корректно ограничены подписанные URL.
Проверка должна включать анализ конфигурации, тестирование ACL и Bucket Policy, просмотр CORS, проверку логирования и изучение поведения кэшей. Такой аудит безопасности S3 интеграций помогает выявить проблемы до выхода сервиса в эксплуатацию.
Не менее важно регулярно пересматривать права доступа. Устаревшие ключи необходимо отзывать, секреты - хранить вне исходного кода, а сервисным аккаунтам выдавать минимально необходимые разрешения. Для публичных файлов лучше использовать отдельный бакет без доступа к внутренним данным.
Итог
S3 удобен и масштабируем, но его безопасность определяется не только настройками облака. Ошибки в проксировании, политиках доступа, обработке загружаемых файлов, кэшировании и генерации URL способны превратить обычное хранилище в точку компрометации приложения.
Комплексный подход - от корректной модели разрешений до регулярного тестирования - позволяет снизить риски. При этом поиск bug bounty S3 уязвимости должен проходить только в пределах разрешённой программы или на принадлежащей исследователю инфраструктуре. Именно сочетание аккуратной конфигурации, изоляции пользовательского контента и постоянного контроля делает безопасность S3 хранилища данных действительно устойчивой.
