OWASP TOP10 — №10 по непроверенным редиректам и переадресациям

Question

Я прочитал много статей на эту тему, в том числе СТРАНИЦА OWASP и Статья в блоге Google об открытых редиректах...
Я также нашел этот вопрос на открыть перенаправления здесь при переполнении стека но это другой

Я знаю, почему мне не следует перенаправлять...для меня это имеет смысл.

Но вот чего я действительно не понимаю:В чем именно разница между перенаправлением и помещением этого в обычный <a href связь?
Возможно, некоторые пользователи смотрят на строку состояния, но я думаю, что большинство из них на самом деле не смотрят на строку состояния, когда нажимают ссылку.
Неужели это единственная причина?как на этом статья они написали:

<a href="http://bank.example.com/redirect?url=http://attacker.example.net">Click here to log in</a>

Пользователь может предположить, что ссылка безопасна, поскольку URL-адрес начинается с доверенного банка, bank.example.com.Однако затем пользователь будет перенаправлен на веб-сайт злоумышленника (attacker.example.net), который злоумышленник, возможно, сделал очень похожим на bank.example.com.Затем пользователь может невольно ввести учетные данные на веб-страницу злоумышленника и скомпрометировать свой банковский счет.Сервлет Java никогда не должен перенаправлять пользователя на URL-адрес без проверки того, что адрес перенаправления является надежным сайтом.

Итак, если у вас есть что-то вроде гостевой книги, где пользователь может разместить ссылку на свою домашнюю страницу, то единственное отличие состоит в том, что ссылка не перенаправляется, но все равно ведет на вредоносную веб-страницу.

Я правильно вижу эту проблему?

Answer 1

Насколько я понимаю, проблема не в редиректе.Основная проблема здесь — разрешение перенаправления (когда цель потенциально контролируется пользователем), содержащего абсолютный URL-адрес.

Тот факт, что URL-адрес является абсолютным (то есть он начинается http://host/etc), означает, что вы непреднамеренно разрешаете междоменное перенаправление.Это очень похоже на классические уязвимости XSS, благодаря которым JavaScript может быть использован для выполнения междоменных вызовов (и утечки информации о вашем домене).

Итак, насколько я понимаю, способ исправить большинство подобных проблем — убедиться, что любое перенаправление (на сервере) выполняется относительно корня.Тогда значение строки запроса, управляемое пользователем, не сможет перейти куда-то еще.

Это отвечает на ваш вопрос или просто создает нечто большее?

Answer 2

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

Цель перенаправления не обязательно должна быть такой очевидной, как в примере.На самом деле злоумышленник, вероятно, будет использовать дополнительные методы, чтобы обмануть как пользователя, так и, возможно, даже веб-приложение, если необходимо, с помощью специальных кодировок. загрязнение параметров, и другие методы подделки законного URL-адреса.

Таким образом, даже если жертва настолько заботится о безопасности, что проверяет URL-адрес перед тем, как щелкнуть ссылку или в противном случае запросить ее ресурс, все, что она может проверить, это то, что URL-адрес указывает на заслуживающий доверия веб-сайт. банк.example.com.И одного этого слишком часто бывает достаточно.