Возможная SSRF в теге изображения, который принимает (частичный) ввод пользователя?

На чтение 3 мин Опубликовано 09.10.2024

Вопрос или проблема

В веб-приложении есть тег img, который частично принимает пользовательский ввод, например:

<img src="/blah/blah/$USERINPUT.jpg">

где первый / расположен от корня домена.

Может ли здесь быть уязвимость? Потенциально с использованием ../ и попыткой выполнить обход по пути?

Здесь несколько противоречивых моментов.

SSRF (Server-Side Request Forgery) — это когда вы заставляете сервер запрашивать (обычно иностранный) URL от вашего имени. Это не совсем то же самое, что и обход по пути. Обход по пути может быть возможен, но я был бы удивлен — лучшим индикатором обхода по пути было бы имя файла внутри части запроса URL или внутри данных POST.

Ваш лучший шанс на обнаружение проблемы с отображенным пользовательским вводом — это обычно межсайтовый скриптинг (XSS). Если вы изменяете пользовательский ввод, экранируются ли кавычки?

Если вы не упускаете информацию о каком-то серверном рендерере, вы не найдете здесь SSRF. SSRF заставляет сервер загружать контент; изменение тега изображения влияет только на HTML, а HTML будет просто отображен на клиенте.

Если вы тестируете обход по пути, нет необходимости пытаться сделать это через тег изображения. Просто запросите страницу с ../../ в пути. Тем не менее, я тоже был бы удивлен, если это сработает.

Ответ или решение

В данном случае мы рассматриваем потенциальную уязвимость в веб-приложении, которое использует тег <img> с частичным пользовательским вводом в URL изображения. Код выглядит следующим образом:

<img src="/blah/blah/$USERINPUT.jpg">

Где $USERINPUT — это часть, которую подставляет пользователь.

Возможные уязвимости:

Path Traversal (Путевая уязвимость):
- Да, существует возможность использовать символы ../ для попытки обхода системных ограничений и доступа к файлам, расположенным вне запрашиваемой директории. Однако, это может быть ограничено серверными настройками или механизмами проверки входящих данных. В такой ситуации стоит исследовать, как именно сервер обрабатывает предоставленный пользовательский ввод, и применяются ли меры противодействия, такие как валидация и нормализация пути.
Server-Side Request Forgery (SSRF) (Уязвимость Подачи Запросов от Имени Сервера):
- В данном конкретном случае уязвимость SSRF не будет возникать, так как тег <img> не инициирует сетевой запрос от имени сервера, а лишь отображает содержимое на стороне клиента. SSRF возникает, когда сервер встраивает удаленные URL и делает запросы, рассказывая об этом. Поскольку в вашем примере явно не идет речь о серверном запросе к произвольному URL, его нельзя квалифицировать как SSRF.
Cross-Site Scripting (XSS) (Межсайтовый Скриптинг):
- Атаки типа XSS также могут быть значимой угрозой, если пользовательский ввод не фильтруется должным образом. Если данные не экранируются или не очищаются, то злоумышленник может попытаться внедрить JavaScript-код через вставку пользовательского ввода, что может вызвать нежелательное поведение на стороне клиента.

Рекомендации по безопасной обработке пользовательского ввода:

Валидация и нормализация: Всегда проверяйте вводимые данные. Если ожидался только буквенно-цифровой ввод для имени файла, используйте регулярные выражения для его проверки.
Экранирование: Экранируйте или удаляйте специальные символы, такие как .., чтобы предотвратить попытки путевого обхода.
Использование безопасного пути: Генерируйте полные пути к файлам на стороне сервера, а не полагаясь на пользовательский ввод. Например, храните корневую директорию файлов, и добавляйте к ней ввод пользователя, предварительно проверив его.
Регулярные проверки безопасности: Проводите тестирование на уязвимости, чтобы своевременно обнаруживать возможные проблемы, такие как XSS или непреднамеренная утечка данных.

Таким образом, в данном случае явных уязвимостей, связанных с SSRF, нет, но возможны проблемы с XSS и путевым обходом, которые требуют внимания.