Эксплуатируем Open Redirect. Как открытый редирект используют для фишинга и DDoS

Содержание статьи

• Разбираемся глубже в Open Redirect
• Откуда появляется уязвимость?
• Как самому найти уязвимость?
• Эксплуатация уязвимости. Основные угрозы
• Фишинг
• Совмещение с другой уязвимостью
• Open Redirect для DDoS
• Открытая уязвимость в Google
• Доставка ссылки
• Методы атак
• Итог

Уязвимости типа 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. Другие трюки ты можешь посмотреть по ссылкам.

WWW

• Random Robbie payloads
• EdOverflow CheatSheet
• Ak1t4 payloads
• Cujanovic payloads

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

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

Материалы из последних выпусков можно покупать отдельно только через два месяца после публикации. Чтобы продолжить чтение, необходимо купить подписку.

Подпишись на «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Уже подписан?

Источник