Безопасно ли перенаправить на URL, например, так: "https://example.com/" + userData?

Question

Могу ли я безопасно использовать данные пользователя при перенаправлении на URL-адрес моего собственного домена?

Предположим, что я владею example.com.Если нормальное использование моего приложения потребует от меня перенаправления пользователей на URL-адреса, подобные этому, это нормально?

https://example.com/ + userData

Есть ли в любом случае это можно использовать, чтобы сделать эксплойт и запустить, например, javascript?или перенаправить на совершенно другой домен?

Для целей этого обсуждения я хотел бы:

• игнорировать атаки обхода каталога * только 1014 *
• Рассмотрим атаки, которые влияют на браузер (не сервер example.com)

Можно предположить, что я вообще не кодирую параметр, полученный от пользователя.

РЕДАКТИРОВАТЬ: Уточнение - userData не добавляется на страницу в любом случае - он находится только в самом URL.

Answer 1

1. Это может быть точка для фишинг-атаки

Злоумышленник может отправлять электронную почту, притворяясь письмом с вашего сайта, и вставлять ссылку аналогично (я полагаю, что «jumper.php» - это страница, котораяимеет один параметр URL с целевым URL, который может содержать данные пользователя):

Чтобы подтвердить свой аккаунт, перейдите по этой ссылке: http://example.com/jumper.php?url=http%3A%2F%2Fexample-my.com

В этом случае пользовательувидит в почтовой ссылке, начинающейся с http://example.com, и может предположить, что это действительная ссылка на ваш сайт, но на самом деле он будет перенаправлен на http://example-my.com, который может контролироваться злоумышленником (и очень похож на ваш сайт).

В некоторых случаях люди используют javascript для перенаправления

Если страница содержит код, подобный этому (пример php):

<script>location.replace(<?= json_encode($userData) ?>);</script>

Тогда даже переменная должным образом очищается,Злоумышленник может выполнить произвольный код JavaScript в контексте http://example.com с перенаправлением на javascript:....Например:

Чтобы подтвердить свой аккаунт, перейдите по этой ссылке: http://example.com/jumper.php?url=javascript%3Aalert%28document.cookie%29

В этом случае перенаправление будет преобразовано в

<script>location.replace("javascript:alert(document.cookie)");</script>

и код javascript:alert(document.cookie) (как пример) будет выполнен в контексте http://example.com.Несомненно, злоумышленник может сделать гораздо больше с помощью произвольного кода javascript.

Answer 2

Предположим, что код перенаправления выполняется путем добавления, выглядит следующим образом (пример php): header("Location: http://example.com/".$userData);

Поскольку $userData никак не кодируется, фактически злоумышленник может получить доступ к HTTP-ответу.генерируется сервером.Например, $userData может содержать что-то похожее:

"somepage.php\r\nattacker-header:some value\r\n\r\nattacker page body with JavaScript"

В то время как большинство библиотек http (включая php начиная с 5.1.4 AFAIK) предотвращает этот тип атаки header injection и будетгенерировать ошибку, некоторые старые инструменты могут быть уязвимы.

Answer 3

Как уже упоминалось в комментариях , этот сценарий, по-видимому, нельзя использовать с псевдопротоколом javascript: (или data:, который также можно использовать для выполнения JavaScript).Однако может оказаться возможным выполнить отраженную атаку XSS, если example.com выведет userData на пользовательской странице 404.Предположим, что на этой странице отображается сообщение об ошибке:

<h1>Page 'userData' not found.</h1>

В этом случае, если злоумышленник отправит полезную нагрузку JavaScript (например, <script>alert('xss');</script>), она будет отображена на странице,

<h1>Page '<script>alert('xss');</script>' not found.</h1>  

и код может быть выполнен посетителем.Эту атаку можно предотвратить, отфильтровав пользовательские данные - пользовательский ввод всегда должен быть очищен в любом случае.

Эксплойт с открытым перенаправлением не кажется очень вероятным, потому что пользовательский ввод добавляется в домен, и попытки эксплойта должны привести к ответу 404.Конечно, если есть другие локальные страницы, которые разрешают любые перенаправления, то злоумышленник может использовать их в своей полезной нагрузке, например:

vulnerable/page?url=http://attacker.com

Обратите внимание, что только потому, что я не могу подтвердить эксплойт, который не делаетозначает, что код не уязвим, в зависимости от конфигурации сервера.Мы можем предотвратить эксплойты с открытым перенаправлением, отфильтровывая пользовательские данные на основе списка допустимых и надежных расположений.Это также может помочь с несколькими другими атаками, нацеленными на сервер, такими как обратный путь в каталогах, включение файлов и подделка запросов на стороне сервера.