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

• Откуда появляется уязвимость?
• Эксплуатация уязвимости. Основные угрозы
• Совмещение с другой уязвимостью
• Открытая уязвимость в 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);
?>
[/code]

Тогда уязвимая ссылка будет такой: 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);
}
}
}
[/code]

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

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

Click here to log in
[/code]

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

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

Теги: CSS, Open уязвимость сайт будет ссылка