Уязвимости типа Open Redirect позволяют перенаправить пользователя на фишинговый сайт или заставить скачать руткит под видом полезного ПО. Несмотря на всю опасность этих уязвимостей, закрывать их не спешат даже в Google. Давай разберемся, почему так вышло и как работают разные атаки с Open Redirect.

Редирект позволяет направить пользователя с одного сайта на другой — это знают все. Что же тогда такое Open Redirect («открытое перенаправление»)? Звучит как название какого-то свободного стандарта, но в реальности так называют уязвимость, которая позволяет незаметно направить пользователя на любой сайт с доверенного домена.

WARNING

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

В основном этот баг используется для фишинга. Злоумышленник перенаправляет с уязвимого доверенного сайта на свой фишинговый сайт и крадет данные. Эта уязвимость активно применялась хакерами при атаках на государственные сайты.

Представь, что получится, если сайт apple.com станет разрешать редирект на apple.evil.com. Пользователь будет думать, что он находится на доверенном сайте, но при этом оставлять свои данные на сайте злоумышленника. Кстати, подобную уязвимость уже находили.

А что, если прямо сейчас в Google открыта такая уязвимость? Пользователь заходит на свою почту по ссылке google.com, вводит данные. Возможно, он проверяет адресную строку браузера и URL, но в ней все в порядке. Затем попадает на страницу с письмами и видит привычную ежедневную картину. Как часто в этот момент пользователи проверяют адресную строку? А ведь свирепые русские хакеры не дремлют!

 

Разбираемся глубже в Open Redirect

К примеру, у нас есть доверенный сайт http://site.com/. Но в нем есть уязвимость Open Redirect, которая будет выглядеть так: http://site.com/login?redirectUrl=http://site.com/auth. После авторизации на странице сайта пользователь перенаправляется на http://site.com/auth.

Попробуем заменить http://site.com/auth на http://evil.com/. Получится ссылка http://site.com/login?redirectUrl=http://evil.com/. Если мы перейдем по этой ссылке после авторизации, а нас направляет на evil.com, значит, сайт имеет уязвимость Open Redirect.

 

Откуда появляется уязвимость?

Администраторы сайтов обычно либо не знают о такой уязвимости, либо не сверяют URL перенаправления с разрешенным белым списком, составленным заранее. Уязвимый код на сервере будет выглядеть приблизительно так (пример на PHP):

<?php
$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);
?>

Тогда уязвимая ссылка будет такой: http://site.com/example.php?url=http://evil.com.

А вот аналог на Java — здесь тоже серверное перенаправление.

public class RedirectServlet extends HttpServlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String query = request.getQueryString();
    if (query.contains("url")) {
      String url = request.getParameter("url");
      response.sendRedirect(url);
    }
  }
}

Сервер получает запрос GET с параметром url и перенаправляет браузер на адрес, переданный в URL.

Что до перенаправления на стороне клиента, то оно может выглядеть как-то так:

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

Пользователь думает, что ссылка безопасная, так как начинается с bank.site.com. Однако после перехода он будет перенаправлен на похожий фишинговый сайт.

 

Как самому найти уязвимость?

  • Внимательно пройтись по всем ссылкам сайта и найти в них параметры перенаправления.
  • Как вариант, можно использовать перебор при помощи специальных программ.
  • Ввести в поисковую строку Google site:target.com inurl:redirectUrl=http.
  • Проанализировать, где может использоваться перенаправление. К примеру, редирект после авторизации.
  • Попробовать найти уязвимость с помощью различных известных трюков: target.com/?redirect_url=https://evil.com, target.com//evil.com. Другие трюки ты можешь посмотреть по ссылкам.
 

Эксплуатация уязвимости. Основные угрозы

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Check Also

Android-троян FANTA нацелен на пользователей Avito

Зафиксирована новая кампания Android-трояна FANTA, атакующего клиентов 70 банков, платежны…

4 комментария

  1. Аватар

    Proctor_art

    12.10.2018 at 11:21

    ХАКЕР Вы же уже писали про обфускацию(где-то так в 11году) разве я не прав- это старые грабли на новом газоне

  2. Аватар

    Proctor_art

    12.10.2018 at 11:54

    А вообще с обфускацией кода раньше делали регистрацию: рег на фейк странице , фейк стр отправляла на реальную(hijack) и все данные оседали на серве где стоит фейк с редиректом. Вся инфа ждала время когда она потребуется(это раньше БД),да и до сих пор сайты (человек) уязвимое место

  3. Аватар

    cherezzabo

    09.03.2019 at 16:05

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

  4. Аватар

    duodai

    28.05.2019 at 09:31

    Отличная статья. За ссылки отдельное спасибо 🙂

Оставить мнение