SSRF: как заставить сервер атаковать самого себя и почему обычной проверки URL недостаточно
A common feature lets a user paste an image URL so the application can download it and set it as an avatar. On the surface this seems safe: the server simply sends an HTTP request to the given address, receives an image, and saves it. The SSRF risk appears when the supplied address points to an internal service rather than an image, raising the problem that checking the URL in the usual way is not enough.
Представим обычный функционал: пользователь вставляет ссылку на изображение, а приложение скачивает его и устанавливает в качестве аватара. На первый взгляд ничего опасного. Сервер просто отправляет HTTP-запрос по указанному адресу, получает картинку и сохраняет её. Но есть один нюанс: а что, если вместо ссылки на изображение пользователь передаст адрес внутреннего сервиса, который вообще не должен быть доступен извне? Например, внутренней административной панели, Redis, Elasticsearch или облачного сервиса метаданных. Именно на таком принципе работает SSRF — Server-Side Request Forgery. Уязвимость позволяет заставить сервер самостоятельно отправлять запросы туда, куда пользователь напрямую обратиться не может. — Разберём, как возникает SSRF, почему простые фильтры не спасают и какие меры действительно помогают защитить приложение. Читать далее