Согласно Open Web Application Security Project, открытое перенаправление происходит, когда приложение принимает параметр и перенаправляет пользователя к значению этого параметра без какой-либо валидации и проверки содержимого этого параметра.
Эта уязвимость используется в фишинговых атаках, чтобы заставить пользователей посетить вредоносные сайты усыпляя их бдительность. Вредоносный веб-сайт будет выглядеть при этом точно также как и настоящий, с той лишь разницей что задача вредоносного сайта собирать личную и конфиденциальную информацию.
Примеры Уязвимости Открытого Перенаправления
1. Открытое перенаправление при установке темы оформления для Shopify
Сложность: Низкая
Url: app.shopify.com/services/google/themes/preview/supply–blue?domain_name=XX
Ссылка на отчет: https://hackerone.com/reports/10196236
Дата отчета: 25 ноября 2015
Описание:
Платформа Shopify позволяет администраторам магазина настраивать внешний вид своих магазинов. При этом администраторы устанавливают сторонние темы оформления. Уязвимость была обнаружена в том, что страница установки темы оформления в адресе запроса была определена как параметр перенаправления и вернула 301 редирект в браузер пользователя без проверки домена перенаправления.
В результате, если пользователь зайдёт по адресу https://app.shopify.com/serviblue?domain_name=example.com, он будет перенаправлен на страницу http://example.com/admin.
Злоумышленник мог бы разместить сайт на этом домене, чтобы попытаться провести фишинг-атаки на ничего не подозревающих пользователей.
[ad name=»Responbl»]
Выводы
Рискну лишний раз повториться, но не все уязвимости являются сложными. Открытая переадресация в данном случае просто требует изменения параметра перенаправления на внешний сайт.
2. Открытое перенаправление входа в Shopify
Сложность: Средняя
Url: http://mystore.myshopify.com/account/login
Ссылка на отчет: https://hackerone.com/reports/10377237
Дата отчета: 6 декабря 2015
Описание:
Это открытое перенаправление очень схоже с уязвимостью при установке темы оформления, описанной выше, но здесь уязвимость возникает после того, как пользователь уже вошел в систему с помощью оформления заказа ?checkout_url. Например:
http://mystore.myshopify.com/account/login?checkout_url\=.np
В результате, когда пользователь посещает эту ссылку и вхо- дит в систему, он будут перенаправлен на: https://mystore.myshopify.com.np/
который на самом деле не является доменом исходного магазина Shopify!
[ad name=»Responbl»]
3. Промежуточное перенаправление HackerOne
Сложность: Средняя
Url: Недоступен
Ссылка на отчет: https://hackerone.com/reports/11196838
Дата отчета: 20 января 2016
Описание:
Промежуточное перенаправление — это простое перенаправление, следующее за другим перенаправлением, где окончательное перенаправление становится возможным после указания на него первым.
HackerOne фактически предоставил текстовое описание этой уязвимости в своём докладе:
Ссылки домена hackerone.com рассматривались как надёжные ссылки, в том числе с последующим параметром /zendesk_session. Любой пользовательмог создать пользовательскую учетную запись Zendesk, которая дальше перенаправляла пользователя на ненадежный веб-сайт и передавала все параметры в /redirect_to_account?state=param; поскольку Zendesk разрешает перенаправления между учётными записями напрямую, без промежуточных переадресаций, пользователь перенаправлялся в ненадежное место без какого-либо предупреждения.
Учитывая что происхождение этой уязвимости находится в пределах Zendesk, мы решили использовать ссылки с zendesk_session в качестве внешних ссылок, которые генерировали бы иконку и промежуточную страницу предупреждения при нажатии.
Также, Махмуд Джамал (да, тот самый Махмуд из Google XSS уязвимости) создал compayn.zendesk.com и добавил:
<script>document.location.href = ”http://evil.com”;</sc\ 2 ript>
в заголовок файлов через редактор темы оформления zendesk. Затем, прошёл по ссылке:
https://hackerone.com/zendesk_session?locale_id=1&retur\ n_to=https://support.hackerone.com/ping/redirect_to_acc\ ount?state=company:/
которая используется для переадресации для создания сеанса Zendesk.
И что интересно, Махмуд сообщил Zendesk об этой проблеме перенаправлений сразу же. Однако, они отметили, что они не замечали какой-либо проблемы с этой уязвимостью. Поэтому, естественно, Махмуд продолжал свои исследования, чтобы понять, как эта уязвимость может быть использована.
[ad name=»Responbl»]
Выводы
Мы уже обсуждали это в главе Authenticate, но стоит повторить еще раз. Как и при поиске уязвимостей, примите к сведению, что каждый из использующихся сервисов сайта представляет собой новый вектор атаки во время поиска. При этом, указанная в примере уязвимость была возможна благодаря сочетанию использования HackerOne с Zendesk и знанием о том, какие перенаправления они позволяют совершать.
Кроме того стоит учесть, что когда вы находите ошибки и уязвимости, до момента их исправления может пройти много времени, прежде чем ваш отчёт о найденной уязвимости прочитают, поймут, и на него отреагируют. Вот почему у меня есть глава Отчеты об уязвимостях. Более тщательная работа, а также детализированность и вежливость в вашем отчёте поможет обеспечить более глубокое понимание вопроса тем, кто занимается вопросами защиты информации, и как следствие более быструю реакцию.
Но некоторые компании даже не смотря на то, о чём я говорил, будут с вами не согласны. Если это так, смело продолжайте копать, как это сделал Махмуд. Вы можете доказать существование реальной угрозы безопасности эксплуатацией и демонстрацией возможности этой уязвимости на деле.
[ad name=»Responbl»]
Итоги
Открытое перенаправление интересная уязвимость. Она позволяет злоумышленнику перенаправлять ничего не подозревающих людей на вредоносные сайты. Нахождение этих уязвимостей, как показывают примеры, часто требуют наблюда-
тельности. Иногда их легко найти по строчками redirect_to=, domain_name=, checkout_url=, и подобным. Этот тип уязвимости полагается на использование доверия, когда жертвы посещают сайт хакера, думая, что они посетят знакомый сайт.
Как правило, вы можете обнаружить эту уязвимость, когда URL передается в качестве параметра для веб-запроса. Следите за адресом и “играйте” с ним, чтобы увидеть, примет ли он ссылку на внешний сайт.
Кроме того, промежуточное перенаправление от HackerOne показывает важность того, что и инструменты и сервисы вебсайтов могут содержать уязвимости, и что иногда необходимо проявить настойчивость, наглядно демонстрировать уязвимость, прежде чем она будет признана и принята.
Советуем ознакомится также с https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet
Оглавление:
Базовые знания о HTTP протоколе. Глава 1
Что такое HTML иньекция. Уроки хакинга. Глава 2.
Что такое HPP (HTTP Parameter Pollution) атака? Уроки хакинга. Глава 3
Что такое CRLF инъекция, примеры использования. Уроки хакинга, Глава 4.
Уязвимости в логике приложений. Уроки хакинга. Глава 6
Уязвимости в логике работы приложений. Примеры.
Что такое XSS атака (Cross Site Scripting Attacks). Уроки хакинга. Глава 7.
SQL иньекции. Виды и примеры использования. Уроки хакинга. Глава 8.
Захват поддомена. Уроки хакинга. Глава 10.
5 comments On Уязвимости Открытого Перенаправления. Уроки хакинга. Глава 9
Pingback: Уроки хакинга. Базовые знания о HTTP протоколе. Глава 1 - Cryptoworld ()
Pingback: Что такое CRLF инъекция, примеры использования. Уроки хакинга, глава 4. - Cryptoworld ()
Pingback: Уязвимости в логике приложений. Примеры. Уроки хакинга. Глава 6 - Cryptoworld ()
Pingback: SQL иньекции. Виды и примеры использования. Уроки хакинга. Глава 8. - Cryptoworld ()
Pingback: Что такое удаленное выполнение кода. Уроки хакинга - глава 12. - Cryptoworld ()