После успешного входа приложение перенаправляет пользователя на адрес из параметра запроса. Как установить, позволяет ли эта функция выполнить открытое перенаправление?
Проверка должна установить, может ли пользовательский параметр заставить приложение перенаправить браузер на произвольный внешний ресурс. Для этого подставляют внешний адрес и варианты его неоднозначного представления, затем проверяют фактический заголовок перенаправления и конечный адрес в браузере. Уязвимость подтверждена, если сервер принимает неконтролируемый внешний адрес, хотя функция предназначена для перехода только внутри приложения.
Перенаправления после входа появились для возврата пользователя к исходной странице или продолжения сценария после успешной операции. Поэтому приложения начали принимать целевой адрес из запроса, но без строгой проверки эта удобная функция превратилась в открытое перенаправление.
Проблема особенно опасна в ссылках на доверенный домен: пользователь видит знакомый адрес, а затем незаметно оказывается на внешнем сайте. Само перенаправление обычно не даёт атакующему полномочий в приложении, но повышает достоверность фишинга и может участвовать в атаках на другие механизмы, если они ошибочно доверяют промежуточному адресу.
Сначала нужно определить ожидаемое поведение. Если приложение должно возвращать пользователя только на страницы своего ресурса, внешний абсолютный адрес, другой источник или неоднозначная форма URL должны быть отклонены либо заменены безопасным маршрутом по умолчанию.
Тестировщик отправляет запрос с обычным внутренним адресом и фиксирует результат, затем повторяет его с внешним адресом. Важно проверить не только тело ответа, но и заголовок Location, код ответа и фактический конечный адрес после перехода браузера.
Неверная проверка может принимать адреса из другого домена, если ищет разрешённую строку лишь как подстроку. Дополнительные ошибки возникают при смешении абсолютных и относительных адресов, обработке обратных слешей, URL-кодирования, учётных данных в URL и разных вариантов регистра имени хоста.
Положительный результат проверки имеет два признака: приложение принимает управляемое пользователем значение, а браузер после ответа действительно уходит на внешний источник. Если значение отражается в ответе, но браузер не выполняет перенаправление, это ещё не подтверждение открытого перенаправления.
Безопасная реализация обычно разрешает только относительные пути внутри приложения либо использует строгий список разрешённых источников. При проверке внешних адресов нужно сначала привести значение к однозначному представлению средствами принятого URL-разборщика, затем сравнивать отдельно схему, хост, порт и допустимый путь. Проверка подстроки имени домена недостаточна.
Предпочтительнее принимать только локальный путь без схемы и имени хоста. Если бизнес-сценарий требует внешних переходов, список разрешённых источников должен быть минимальным, явно заданным и независимым от пользовательского ввода.
Нужно учитывать ограничения теста: редирект сам по себе не доказывает кражу данных, а разрешённый переход на внешний ресурс может быть сознательной бизнес-функцией. Однако неконтролируемый внешний адрес в контексте доверенного домена следует фиксировать как уязвимость или как риск, требующий оценки владельца системы.
В форме входа параметр возврата использовался для перехода к странице, с которой пользователь начал работу. Вариант с относительным внутренним путём работал корректно, а внешний адрес приводил к ответу с перенаправлением за пределы приложения.
Рассматривались три решения. Полностью удалить параметр было самым простым вариантом, но это ухудшало пользовательский сценарий. Проверка по наличию имени доверенного домена была удобной, но допускала поддельные домены с похожей строкой. Разрешение только относительных путей сохранило требуемое поведение и исключило внешний источник.
Выбрали третий вариант, а некорректные значения стали направлять на главную страницу. Повторная проверка подтвердила, что внутренние переходы работают, а внешний адрес больше не приводит к уходу с доверенного ресурса.
Нет. Такой фильтр может пропустить другие формы URL, например адрес без схемы, но с указанием внешнего хоста, или значение, которое после декодирования и нормализации интерпретируется иначе. Надёжнее разрешать ожидаемый формат, а не пытаться перечислить все опасные варианты.
Проверка вхождения строки не показывает границу имени хоста. Значение, содержащее доверенное имя как часть другого домена, может пройти такой фильтр, хотя браузер отправит пользователя на атакующий ресурс. Сравнивать нужно структурированные компоненты URL после канонической обработки.
Нет. Воздействие зависит от контекста, доверия к домену и связности функции с другими потоками. Риск обычно связан с фишингом, обходом ожиданий пользователя и возможным влиянием на интеграции; сам по себе редирект не предоставляет доступ к защищённым данным. Приоритизацию следует проводить с учётом того, какие доверительные отношения и сценарии используют этот адрес.