S3-интеграции: почему заражение начинается не с взлома, а с ошибки в настройке

Прочитал, что в веб-приложениях через S3-интеграции могут скрываться уязвимости, которые позволяют не просто укради данные, а встроить в сайт вредоносный код. Это не про «хакеров, выбранных лично вас» — это про системные дыры, которые обходят боты автоматически. И это касается почти любого сайта, где есть загрузка файлов.

О чём речь и почему я считаю это важным для сайта

Речь о том, как встроенные хранилища в облаке — даже если вы их не видите — могут стать точкой входа для заражения. В статье описано, как уязвимости в настройках прокси (например, nginx) позволяют подменить бакет, внедрить XSS или украсть сессии. Это не про сложные атаки — это про ошибки в конфигурации, которые повторяются у сотен сайтов.

Я считаю это важным, потому что заражение не начинается с «взлома». Оно начинается с того, что кто-то загрузил файл — и система его не проверила. А потом боты считывают этот код и размножают его по всему интернету. Потеря доверия, блокировка в браузерах — это не сюрприз, а следствие.

Как это устроено — что тут вообще происходит

Представьте: у вас есть сайт, где пользователи загружают изображения. Эти файлы хранятся в облаке через S3. Но если прокси (например, nginx) не проверяет, куда идёт запрос, а просто передаёт путь — тогда злоумышленник может изменить имя бакета в URL. Например, /staticxxx превращается в запрос к бакету, который он контролирует.

Из-за этого можно загрузить вредоносный скрипт — например, XSS — и он будет работать на вашем сайте. Более того, через уязвимость можно не только внедрить код, но и перехватить куки, включая HttpOnly, — то есть сессии пользователей. Это не теория — это уже практика, которую боты используют массово.

Как понять, что это касается вашего сайта («как я это проверяю»)

Я смотрю на структуру URL-путей к файлам. Если в пути есть /static, /uploads, /files — и нет явного ограничения на имя бакета, это тревожный сигнал. Особенно если в конфигурации nginx используется $uri или подобные переменные без фильтрации.

Проверяю, как ведёт себя сервер при запросах с нестандартными символами — например, пробелами или символами переноса. Если ответы отличаются от ожидаемых — это может быть признак HTTP Request Splitting. Также смотрю заголовки: если X-Amz-Request-Id есть — значит, используется S3-совместимая система, и это требует проверки.

Что с этим делать («что я делаю в таких случаях»)

Первым делом — проверяю, как настроена интеграция S3. Если используется прокси, и нет фильтрации методов, путь и заголовков — это риск. Закрываю доступ к бакетам через публичные URL. Даже если файлы публичные, они должны быть доступны только по защищённым ссылкам с подписью.

Убираю возможность подмены бакетов: добавляю проверку имени бакета на сервере, не доверяю клиентскому пути. Все загрузки проходят через валидацию, а не через прямой проксирование. Проверяю, нет ли в коде уязвимостей, связанных с обработкой URL-путей.

Что здесь даёт поддержка. Как мы закрываем причину, а не только следствие

Мы не просто убираем вредоносный код. Мы находим, откуда он попал — и закрываем дыру. Проверяем конфигурацию прокси, смотрим, как обрабатываются запросы к S3. Включаем логирование и мониторинг на подозрительные запросы: например, PUT с нестандартным путём или с параметром Expires.

Проверяем политики доступа: ACL и Bucket Policy. Убеждаемся, что AuthenticatedUsers не даёт доступа к бакетам. Используем минимальные привилегии. Всё, что можно, делаем через серверные проверки, а не через клиентский путь. И проверяем, что все загрузки проходят через безопасные, подписанные ссылки.