Уязвимость Open Redirect

11.09.202011.09.2020 Editorial Team 1 Comment 10 588 просмотров

Spread the love

Перевод статьи: s0cket7 — Open Redirect Vulnerability

TL;DR

Этот пост рассказывает об уязвимостях Open/Unvalidated Redirects и Forwards. Вы узнаете, что они из себя представляют, как их найти, как их использовать и как их исправить.

Что стоит отметить

Требуются базовые знания о HTTP.
Если у вас есть знания в области программирования, это тоже поможет, потому что мы рассмотрим некоторый код в этом посте.

Введение

Что такое перенаправление (Redirects)?

Перенаправление означает, что веб-сайт может перенаправить запрос ресурсов на другой URL/конечную точку. Предположим, что вы отправляете запрос на apple.com, а apple.com может перенаправить вас на другой сайт (new-apple.com), так что вы окажетесь на new-apple.com, даже если исходный запрос был сделан для apple .com. Это называется «перенаправление». Существуют различные типы перенаправлений в HTTP.

Стандартные коды статусов перенаправлений — 3xx

300 Multiple Choices множество выбора
301 Moved Permanently перемещено навсегда
302 Found найдено
303 See Other смотреть другое
304 Not Modified не изменялось
305 Use Proxy использовать прокси
307 Temporary Redirect временное перенаправление
308 Permanent Redirect постоянное перенаправление

Перенаправление может происходить на стороне сервера (Server-Side) или на стороне клиента (Client-Side).

Server-Side: Запрос на перенаправление отправляется на сервер, затем сервер уведомляет браузер о перенаправлении на URL-адрес, указанный в ответе.

Client-Side: Браузер получает уведомление о перенаправлении на указанный URL-адрес напрямую, без вмешательства сервера.

Что такое Open Redirects?

Open redirect (Открытое перенаправление) это то, что написано в названии: Открытое (Open) перенаправление (Redirects) на любой веб-сайт.

Почему это проблема?

Ну, это плохо с самого начала, подумайте об этом на мгновение, что если apple.com, ДОВЕРЕННЫЙ веб-сайт, позволяет вам перенаправить на любой другой веб-сайт. Тогда злонамеренный пользователь может просто перенаправить apple.com на attacker.com, и люди все время будут думать что они находятся на apple.com, полагая, что ему доверяют, но на самом деле это не так. Поэтому разрешать перенаправления на любой веб-сайт без проверки или без надлежащего уведомления пользователя — это плохо.

Объяснение

Допустим, есть «хорошо известный» веб-сайт — https://example.com/. И давайте предположим, что есть ссылка, как

https://example.com/signup?redirectUrl=https://example.com/login

Эта ссылка на страницу регистрации, после регистрации вы будете перенаправлены на https://example.com/login, который указан в URL-адресе в GET параметре redirectUrl.

Что произойдет, если мы изменим example.com/login на attacker.com?

https://example.com/signup?redirectUrl=https://attacker.com/

Посещая этот URL, если после регистрации мы будем перенаправлены на attacker.com, это означает, что у нас есть открытая уязвимость перенаправления. Это классический открытый редирект и часто используется для фишинга.

Почему это происходит?

Это происходит из-за недостаточной проверки перенаправления в серверной части, что означает, что сервер неправильно проверяет, находится ли URL-адрес перенаправления в своем белом списке или нет. Вот несколько примеров уязвимого кода

PHP (Server-Side)

<?php 
    $url_to_redirect = $_GET['redirect_url'];
    header('Location: ' . $url_to_redirect);
    die();

Здесь код php слепо захватывает URL-адрес из параметра redirect_url и перенаправляет на этот URL-адрес, используя HTTP-заголовок Location.

Java (Server-Side)

 response.sendRedirect(request.getParameter("u"));

Здесь jsp-страница берет URL-адрес из параметра u и слепо перенаправляет его на указанный URL-адрес.

Javascript (Client-Side)

window.location.href = "https://attacker.com";

Мы можем назначить строку URL для location.href объекта window. Это приведет к перенаправлению. Если там нет проверок, значит, это уязвимость.

HTML (Client-Side)

<meta http-equiv="refresh" content="0;URL='http://attacker.com/'" />

Метатеги HTML могут обновлять сайт с заданным URL-адресом в качестве содержимого (content), а также вы можете указать время задержки перед обновлением.

Как обнаружить эту уязвимость?

Посетите каждую конечную точку цели, чтобы найти параметры «redirect».
Просмотрите истории прокси. Обязательно используйте фильтры.
Простой перебор (Bruteforcing) тоже может помочь найти уязвимость
Вы можете раскрыть многие конечные точки, просто прочитав код JavaScript.
Google — твой друг, поищите в поисковике, пример запроса: inurl:redirectUrl=http site:target.com
Изучите и проанализируйте целевое приложении на наличие потребности перенаправления , например, перенаправление на панель мониторинга после входа в систему или что-то в этом роде.

Немного магии

Тест на базовую модификацию URL как target.com/?redirect_url=https://attacker.com.
Попробуйте с двойными косыми чертами target.com//attacker.com.
Попробуйте target.com/@attacker.com. В этом случае интерпретация будет такой: target.com — это имя пользователя, а attacker.com — это домен.
Тест на интерпритацию javascript javascript:confirm(1).
Попробуйте target.com/?image_url=attacker.com/.jpg, если загружаются ресурсы изображений.
Попробуйте IP-адрес вместо имени домена.
Вы можете пойти дальше с точки зрения представления IP в десятичном, шестнадцатеричном или восьмеричном виде.
Вы также можете попробовать target.com/?redirect_url=target.com.attacker.com, чтобы обойти слабые реализации регулярных выражений.
Китайский разделитель 。в виде точки — https://attacker%E3%80%82com.
Тест на обратную строку unicode(“\u202e”) target.com@%E2%80%AE@attacker.com.
Без слешей https:attacker.com.
Обратные слешы http:/\/\attacker.com или https:/\attacker.com.
Разные домены redirect_url=.jp в результате перенаправляется на target.com.jp который отличаются от target.com.
Попробуйте юникод безумие (включая смайлики) t𝐀rget.com или 𝐀ttacker.com(‘𝐀’ это “\uD835\uDC00”).

Использование уязвимости

Фишинг

Предположим, что целью является example.com. Он имеет страницу восстановления пароля по адресу example.com/forgot-password. Вы вводите адрес электронной почты и нажимаете кнопку «Forgot Password», и вам будет отправлено письмо со ссылкой для сброса пароля, и эта ссылка может выглядеть следующим образом

https://example.com/reset-password/some-random-token?redirect=https://example.com/login

Если мы вмешаемся в параметр redirect и изменим его на

https://example.com/reset-password/some-random-token?redirect=https://attacker.com/login

Это перенаправляет пользователя на злую страницу входа в систему, если исходная и пользователь могут быть фишинговыми.

Сцепление с SSRF

Если вы ничего не знаете о SSRF, вы можете поискать об этом в Google. В любом случае, допустим, у нас есть цель — example.com, и вы обнаружили ошибку SSRF на https://example.com/?get-image=https://images.example.com/cat.jpg. По сути, мы хотим заставить сервер сделать запрос от нашего имени. Мы можем изменить значение параметра get-image, и сервер сделает запрос к этой конечной точке. Но в этом случае он ограничивает запросы своим собственным (под) доменом (ами), например images.example.com. Это означает, что вы можете сделать запрос на * .example.com (Любой поддомен) в качестве сервера и не можете получить доступ ни к чему вне этой области. Допустим, вы также обнаружили ошибку Open Redirect на https://test.example.com/redirect_url=https://www.example.com/, теперь вы можете связать их вместе, чтобы заставить SSRF работать для любого домена, например

Сначала мы используем уязвимость Open Redirect, изменяя параметр redirect_url

https://test.example.com/?redirect_url=https://www.attacker.com/

Затем мы можем использовать это с SSRF, добавив открытый URL-адрес Open Redirect сверху в качестве параметра get-image.

https://example.com/?get-image=https://test.example.com/?redirect_url=https://www.attacker.com/

Теперь это заставит сервер сделать запрос на один из его собственных поддоменов (test.example.com), а затем он будет перенаправлен на attacker.com, чтобы сработала ошибка SSRF.

    -------------     --------------------                       ---------------- 
==> | get-image | ==> | test.example.com | ==> { REDIRECTS } ==> | attacker.com |
    -------------     --------------------                       ----------------

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

“Вы ограничены только вашим воображением.”

Защита от уязвимости

Используйте перенаправления, только если нет другого варианта.
Если вы хотите их использовать, убедитесь, что вы правильно проверяете домены через белый список.
Вы также можете использовать hmac, если хотите, но с этим довольно легко справиться (атаки с расширением длины — length extension attacks), так что не усложняйте вещи, используйте правильный белый список.

Немного полезных ссылок

Список всех уникальных отчетов об Open Redirect Reports на HackerOne, которые я смог найти на первых 20 страницах результатов Google.

Шпаргалки

Этот список может быть не уникальным, очистите дубликаты и отсортируйте их.

Ресурсы

Вот и все, ребята. Спасибо за чтение. Хорошего дня 🙂

– s0cket7

Была ли вам полезна эта статья?

[3 / 5]

Spread the love