OWASP TOP10 - # 10 Непроверенные перенаправления и пересылки

Question

Я прочитал многие статьи на эту тему, включая OWASP PAGE и статью в блоге 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-адрес веб-сайта, которому доверяет жертва, т.е.е. bank.example.com .

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

Answer 2

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

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

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

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