Открытые перенаправления: проверка адреса из параметра next

Что это такое

Страницы входа, обработчики выхода, переключатели языка и обратные вызовы OAuth часто принимают параметр next, returnUrl или redirect и затем отправляют туда браузер. Без проверки https://example.org/login?next=https://evil.example/ становится ссылкой на вашем домене, ведущей на страницу атакующего; памятка OWASP отмечает, что доверенное имя сервера в ссылке делает фишинговую попытку более убедительной. Памятка также рассматривает внутреннюю переадресацию: серверная передача обработки на путь из запроса может обойти контроль доступа.

Почему это важно

Открытые перенаправления сами по себе имеют ограниченную пользу для атакующего, но служат строительным блоком: они придают фишинговым письмам репутацию вашего домена, RFC 9700 описывает утечку кодов авторизации и токенов через открытый перенаправитель на стороне клиента, и они обходят правила «ссылки только на наш домен» в почтовых фильтрах и политиках содержимого.

Как применять

• Предпочитайте отсутствие назначения, задаваемого пользователем: храните ожидаемое место возврата в сеансе или сопоставляйте короткий идентификатор с URL на сервере (первые рекомендации памятки), следя за возможностью перебора идентификаторов.
• Если URL необходимо принимать, используйте разрешительный список, который памятка предпочитает запретительному: принимайте лишь относительные пути, начинающиеся с одиночного / (отклоняйте //host, /\host и всё, что содержит схему), либо разбирайте URL и сравнивайте схему и хост с явным списком разрешённых источников.
• Разбирайте URL штатным парсером платформы, затем проверяйте компоненты. Документация Python указывает, что urlsplit() и urlparse() не проверяют вход, могут вернуть пустые компоненты вместо исключения и что коду, значимому для безопасности, следует проверить осмысленность схемы, хоста и пути, прежде чем доверять им.
• Нормализуйте до сравнения: однократно декодируйте процентное кодирование, переводите хост в нижний регистр, удаляйте пробельные и управляющие символы, отклоняйте формы с данными пользователя (user@host).
• В OAuth сравнивайте redirect_uri с зарегистрированными значениями по точному совпадению, а не префиксу или шаблону: RFC 9700 рекомендует точное сопоставление URI перенаправления и устанавливает, что веб-серверы с такими URI не должны предоставлять открытые перенаправители.
• Ведите тестовый список форм обхода (//evil.example, https:evil.example, /\evil.example, https://example.org.evil.example, https://example.org@evil.example) и проверяйте отклонение каждой.

Подводные камни

Проверка startswith("https://example.org"), которая совпадает и с https://example.org.evil.example. Проверка до декодирования, а перенаправление после него. Разрешение любого поддомена, когда один размещает пользовательское содержимое. Парсер проверки и парсер браузера могут расходиться: документация Python отмечает, что её функции включают элементы WHATWG URL Standard и RFC 3986, но не соответствуют полностью ни одному, поэтому проверяйте действия браузера с принятым значением, а не только его смысл с точки зрения сервера.