Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
>
>
>
V5623. OWASP. Possible open redirect...
menu mobile close menu
Проверка проектов
Дополнительная информация
toggle menu Оглавление

V5623. OWASP. Possible open redirect vulnerability. Potentially tainted data is used in the URL.

12 Май 2022

Анализатор обнаружил перенаправление с одного ресурса на другой. Причём URL-адрес для перенаправления был получен из внешнего источника и не был проверен. Это может стать причиной возникновения уязвимости типа open redirect, если адрес будет скомпрометирован.

Уязвимости типа open redirect относятся к категории рисков OWASP Top 10 Application Security Risks 2021: A1:2021- Broken Access Control.

Приведём пример:

void Foo()
{
  string url = Request.QueryString["redirectUrl"];
  ....
  if (loggedInSuccessfully)
    Response.Redirect(url);
}

В этом примере 'url' может содержать заражённые данные, так как они получены из внешнего источника. Эти данные используются для перенаправления клиента на адрес, который записан в 'url'. Подобная логика работы программы упрощает проведение фишинговых атак для кражи данных пользователя.

Пример скомпрометированного адреса:

URL: http://mySite.com/login?redirectUrl=http://attacker.com/

Возможный сценарий проведения атаки:

  • пользователь получает ссылку от злоумышленника и под каким-то предлогом переходит по ней;
  • он оказывается на известном сайте, который запрашивает авторизацию. После ввода логина и пароля произойдёт перенаправление на поддельный сайт, который выглядит в точности как ожидаемый;
  • фишинговый сайт также запрашивает логин и пароль. Пользователь думает, что ошибся и снова вводит данные для авторизации;
  • соответственно, их получает злоумышленник, создавший поддельный сайт. После этого происходит перенаправление на оригинальный сайт. В итоге пользователь может даже не заметить, что его данные были украдены.

Главная опасность open redirect состоит в том, что ссылка, полученная от злоумышленника, фактически ведёт на сайт, которому пользователь доверяет. Следовательно, жертва с большей вероятностью перейдёт по ней.

Для защиты open redirect стоит проверять, что перенаправление осуществляется на локальный адрес или на адрес из белого списка.

Приведём пример борьбы с уязвимостью типа open redirect. Используя метод 'IsLocalUrl' из пространства имён 'Microsoft.AspNet.Membership.OpenAuth' можно проверить, что адрес является локальным:

void Foo()
{
  string url = Request.QueryString["url"];
  if (OpenAuth.IsLocalUrl(url))
    Response.Redirect(url);
  else 
    throw ....; 
}

Происходит проверка, что полученный URL-адрес является локальным и только в этом случае осуществляется переход по нему.

Анализатор также считает источниками небезопасных данных параметры методов, доступных из других сборок. Более подробно эта тема раскрыта в заметке "Почему важно проверять значения параметров общедоступных методов".

Рассмотрим пример:

public class UriHelper
{
  public void ProcessUrlQuery(HttpResponse resp, string url)
  {
    RedirectUrl(url, resp);
  }

  private void RedirectUrl(string redirectUrl, HttpResponse resp)
  {               
    resp.Redirect(redirectUrl); 
  }
}

Анализатор обнаружит, что небезопасные данные из параметра 'url' передаются в метод 'RedirectUrl', внутри которого они без проверки используются для перенаправления.

Защититься в данном случае можно тем же способом, что был приведён ранее.

Выявляемые диагностикой ошибки классифицируются согласно ГОСТ Р 71207–2024 как критические и относятся к типу: Ошибки непроверенного использования чувствительных данных (ввода пользователя, файлов, сети и пр.).

Данная диагностика классифицируется как: