Одной из наиболее распространенных и тем не менее игнорируемых веб-разработчиками уязвимостей является Open Redirect (также известная как Непроверенные переадресации и пересылки). Веб-сайт считается уязвимым для Open Redirect, если значения параметра (часть URL-адреса после ?) в HTTP GET-запросе позволяет перенаправить пользователя на новый сайт без проверки целевого сайта. В зависимости от архитектуры уязвимого сайта, перенаправление может произойти после определённых действий, таких как вход в систему, а иногда это может произойти мгновенно при загрузке страницы.
Пример уязвимой ссылки выглядит примерно так: www.example.com/login.html?RelayState=http%3A%2F%2Fexample.com%2Fnext
В этом примере параметр RelayState указывает куда нужно перенаправить пользователя после успешного входа в систему (в нашем примере это example.com/next). Если сайт не проверяет значение параметра RelayState на предмет легитимности и безопасности, то злоумышленник может воспользоваться этим параметром, чтобы перенаправить жертву на фейковую страницу, созданную самим злоумышленником: www.example.com/login.html?RelayState=http%3A%2F%2FEvilWebsite.com
Уязвимости типа Open Redirect обделены вниманием со стороны разработчиков, поскольку они не наносят прямого ущерба сайту и не дают злоумышленнику возможности напрямую украсть данные компании. Однако, это не означает, что Open Redirect не угроза. Одно из основных применений атак такого типа это проведение эффективных и надежных фишинговых атак.
Когда при фишинговой атаке используется Open Redirect, жертва может получить электронное письмо, которое выглядит вполне правдоподобно, со ссылкой, которая указывает на корректный и знакомой жертве домен. Чего жертва может не заметить, так это того, что в середине URL-адреса есть параметры, которые изменяют конечную точку перенаправления. Дабы усложнить выявление Open Redirect, перенаправление может произойти после того, как жертва введет логин и пароль на неподдельном сайте. Злоумышленники обнаружили, что эффективный способ обмануть жертву это перенаправить ее на фейковый сайт после ввода логина и пароля на настоящем сайте. Фейковый сайт будет выглядеть аналогично настоящему сайту, и он попросит жертву повторно ввести пароль. После того, как жертва сделает это, пароль будет записан злоумышленником, а жертва будет перенаправлена обратно на настоящий сайт. Если все сделано правильно, то жертва решит, что ошиблась с паролем в первый раз и не заметит, что ее имя пользователя и пароль были украдены.
Фишинг используется в большинстве успешных таргетированных взломов, а также регулярно в оппортунистических атаках. Учитывая, насколько часто фишинг встречается в повседневной жизни, уязвимости типа Open Redirect также не стоит сбрасывать со счетов.
Было бы несправедливо выделить какой-то конкретный сайт или компанию, как уязвимую для Open Redirect, потому что эта уязвимость встречается часто. Вместо этого было бы полезно показать, насколько таких сайтов много и насколько легко их найти.
Выполнение поиска по сети это один из лучших способов найти Open Redirect на вашем собственном сайте и в других источниках в интернете в целом.
Поисковик от Google дает гибкость в написании поисковых запросов, в том числе и запросов, которые специально ищут по URL-адресам страниц.
Следующие операторы и специальные символы позволят любому пользователю создавать тагретированные запросы, которые могут помочь обнаружить Open Redirect:
-
allinurlоператор, который скажет Google искать в URL-адресе все указанные ключевые слова. Например:allinurl:ReturnUrlбудет искать все веб-страницы, у которых в адресе будет присутствовать часть ReturnUrl. -
siteоператор, который говорит возвращать только те результаты, которые находятся на определенном домене или веб-сайте. Пример:site:example.comкоторый ищет веб-страницы поexample.com. -
""двойные кавычки это специальные символы, который используются для указания на поиск точного сочетания слов и символов внутри кавычек. -
*звездочка знак подстановки, который олицетворяет одно или несколько слов.
Их использование позволяет найти признаки потенциального Open Redirect:
Мы можем искать одновременно присутствие лексем http и https в параметрах GET-запроса. Например:
allinurl:%3Dhttps*allinurl:%253Dhttps*allinurl:%3Dhttp*allinurl:%253Dhttp*
Также мы можем искать специфичные общие слова, связанные с перенаправлением в области параметров GET-запроса. Например:
allinurl:"<keyword>=https"allinurl:"<keyword>=http"allinurl:<keyword>=httpsallinurl:<keyword>=httpallinurl:<keyword>%3Dhttpsallinurl:<keyword>%3Dhttps*allinurl:<keyword>%253Dhttpsallinurl:<keyword>%253Dhttps*allinurl:<keyword>%3Dhttpallinurl:<keyword>%3Dhttp*allinurl:<keyword>%253Dhttpallinurl:<keyword>%253Dhttp*allinurl:<keyword>
Вместо
<keyword>Для целевого поиска, вы можете добавить
site:<domain_name>С помощью такого простого поиска, вы сможете найти десятки уязвимостей типа Open Redirect в течение нескольких минут. В список уязвимых сайтов входят сайты банков, международных корпораций, доверенных компаний, любимых проектов и многочисленные сайты небольших организаций. В качестве дополнительного бонуса, каждый раз, когда поисковый робот Google будет натыкаться на сайты с Open Redirect, мы с помощью запросов будем получать обновленные результаты.
Лучший способ избежать уязвимости Open Redirect это избегать перенаправления по параметру, зависящему от пользователя или приходящего через GET-запрос. Если перенаправление неизбежно, с ним можно совладать, проверив конечный сайт и очистив его репутацию с помощью белого списка подтвержденных URL-адресов.
Я бы посоветовал вам рассказать своим друзьям веб-разработчикам об Open Redirect. Вы можете переслать им эту статью или даже обнаружить уязвимости с помощью метода, упомянутого выше, и сообщить об этом компании с подробным описанием проблемы. Давайте вместе усложним проведение фишинговых атак!
Если вы хотите поделиться своими запросами в Google, которые работают для обнаружения Open Redirect, вы можете сделать это в комментариях.
Узнать подробнее о курсе
