Alvaros
.
- Регистрация
- 14.05.16
- Сообщения
- 21.452
- Реакции
- 101
- Репутация
- 204
Перевод статьи подготовлен в преддверии старта курса
Одной из наиболее распространенных и тем не менее игнорируемых веб-разработчиками уязвимостей является Open Redirect (также известная как «Непроверенные переадресации и пересылки»). Веб-сайт считается уязвимым для Open Redirect, если значения параметра (часть URL-адреса после «?») в HTTP GET-запросе позволяет перенаправить пользователя на новый сайт без проверки целевого сайта. В зависимости от архитектуры уязвимого сайта, перенаправление может произойти после определённых действий, таких как вход в систему, а иногда это может произойти мгновенно при загрузке страницы.
Пример уязвимой ссылки выглядит примерно так:
В этом примере параметр «RelayState» указывает куда нужно перенаправить пользователя после успешного входа в систему (в нашем примере это
Уязвимости типа Open Redirect обделены вниманием со стороны разработчиков, поскольку они не наносят прямого ущерба сайту и не дают злоумышленнику возможности напрямую украсть данные компании. Однако, это не означает, что Open Redirect – не угроза. Одно из основных применений атак такого типа – это проведение эффективных и надежных фишинговых атак.
Когда при фишинговой атаке используется Open Redirect, жертва может получить электронное письмо, которое выглядит вполне правдоподобно, со ссылкой, которая указывает на корректный и знакомой жертве домен. Чего жертва может не заметить, так это того, что в середине URL-адреса есть параметры, которые изменяют конечную точку перенаправления. Дабы усложнить выявление Open Redirect, перенаправление может произойти после того, как жертва введет логин и пароль на неподдельном сайте. Злоумышленники обнаружили, что эффективный способ обмануть жертву – это перенаправить ее на фейковый сайт после ввода логина и пароля на настоящем сайте. Фейковый сайт будет выглядеть аналогично настоящему сайту, и он попросит жертву повторно ввести пароль. После того, как жертва сделает это, пароль будет записан злоумышленником, а жертва будет перенаправлена обратно на настоящий сайт. Если все сделано правильно, то жертва решит, что ошиблась с паролем в первый раз и не заметит, что ее имя пользователя и пароль были украдены.
Фишинг используется в большинстве успешных таргетированных взломов, а также регулярно в оппортунистических атаках. Учитывая, насколько часто фишинг встречается в повседневной жизни, уязвимости типа Open Redirect также не стоит сбрасывать со счетов.
Было бы несправедливо выделить какой-то конкретный сайт или компанию, как уязвимую для Open Redirect, потому что эта уязвимость встречается часто. Вместо этого было бы полезно показать, насколько таких сайтов много и насколько легко их найти.
Выполнение поиска по сети – это один из лучших способов найти Open Redirect на вашем собственном сайте и в других источниках в интернете в целом.
Поисковик от Google дает гибкость в написании поисковых запросов, в том числе и запросов, которые специально ищут по URL-адресам страниц.
Следующие операторы и специальные символы позволят любому пользователю создавать тагретированные запросы, которые могут помочь обнаружить Open Redirect:
Их использование позволяет найти признаки потенциального Open Redirect:
Мы можем искать одновременно присутствие лексем «http» и «https» в параметрах GET-запроса. Например:
allinurl:%3Dhttps*
allinurl:%253Dhttps*
allinurl:%3Dhttp*
allinurl:%253Dhttp*
Также мы можем искать специфичные общие слова, связанные с перенаправлением в области параметров GET-запроса. Например:
allinurl:"=https"
allinurl:"=http"
allinurl:=https
allinurl:=http
allinurl:%3Dhttps
allinurl:%3Dhttps*
allinurl:%253Dhttps
allinurl:%253Dhttps*
allinurl:%3Dhttp
allinurl:%3Dhttp*
allinurl:%253Dhttp
allinurl:%253Dhttp*
allinurl:
Вместо code>keyword>, мы будем использовать одно из следующих слов, характерных для перенаправления: RelayState, ReturnUrl, RedirectUri, Return, Return_url, Redirect, Redirect_uri, Redirect_url, RedirectUrl, Forward, Forward_url, SuccessUrl, Redir, Exit_url, Destination. Здесь приведен далеко не полный перечень ключевых слов. Больше вы сможете найти, проанализировав результаты более общих запросов поиска URL-адреса в разделе параметров GET-запроса.
Для целевого поиска, вы можете добавить «site:code>domain_name>» в конец ваших поисковых запросов в Google. Этот способ может помочь вам найти уязвимости типа Open Redirect на вашем собственном сайте.
С помощью такого простого поиска, вы сможете найти десятки уязвимостей типа Open Redirect в течение нескольких минут. В список уязвимых сайтов входят сайты банков, международных корпораций, доверенных компаний, любимых проектов и многочисленные сайты небольших организаций. В качестве дополнительного бонуса, каждый раз, когда поисковый робот Google будет натыкаться на сайты с Open Redirect, мы с помощью запросов будем получать обновленные результаты.
Лучший способ избежать уязвимости Open Redirect – это избегать перенаправления по параметру, зависящему от пользователя или приходящего через GET-запрос. Если перенаправление неизбежно, с ним можно совладать, проверив конечный сайт и очистив его репутацию с помощью белого списка подтвержденных URL-адресов.
Я бы посоветовал вам рассказать своим друзьям веб-разработчикам об Open Redirect. Вы можете переслать им эту статью или даже обнаружить уязвимости с помощью метода, упомянутого выше, и сообщить об этом компании с подробным описанием проблемы. Давайте вместе усложним проведение фишинговых атак!
Если вы хотите поделиться своими запросами в Google, которые работают для обнаружения Open Redirect, вы можете сделать это в комментариях.
You must be registered for see links
.Одной из наиболее распространенных и тем не менее игнорируемых веб-разработчиками уязвимостей является Open Redirect (также известная как «Непроверенные переадресации и пересылки»). Веб-сайт считается уязвимым для Open Redirect, если значения параметра (часть URL-адреса после «?») в HTTP GET-запросе позволяет перенаправить пользователя на новый сайт без проверки целевого сайта. В зависимости от архитектуры уязвимого сайта, перенаправление может произойти после определённых действий, таких как вход в систему, а иногда это может произойти мгновенно при загрузке страницы.
Пример уязвимой ссылки выглядит примерно так:
You must be registered for see links
В этом примере параметр «RelayState» указывает куда нужно перенаправить пользователя после успешного входа в систему (в нашем примере это
You must be registered for see links
). Если сайт не проверяет значение параметра «RelayState» на предмет легитимности и безопасности, то злоумышленник может воспользоваться этим параметром, чтобы перенаправить жертву на фейковую страницу, созданную самим злоумышленником:
You must be registered for see links
Уязвимости типа 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:"=https"
allinurl:"=http"
allinurl:=https
allinurl:=http
allinurl:%3Dhttps
allinurl:%3Dhttps*
allinurl:%253Dhttps
allinurl:%253Dhttps*
allinurl:%3Dhttp
allinurl:%3Dhttp*
allinurl:%253Dhttp
allinurl:%253Dhttp*
allinurl:
Вместо code>keyword>, мы будем использовать одно из следующих слов, характерных для перенаправления: RelayState, ReturnUrl, RedirectUri, Return, Return_url, Redirect, Redirect_uri, Redirect_url, RedirectUrl, Forward, Forward_url, SuccessUrl, Redir, Exit_url, Destination. Здесь приведен далеко не полный перечень ключевых слов. Больше вы сможете найти, проанализировав результаты более общих запросов поиска URL-адреса в разделе параметров GET-запроса.
Для целевого поиска, вы можете добавить «site:code>domain_name>» в конец ваших поисковых запросов в Google. Этот способ может помочь вам найти уязвимости типа Open Redirect на вашем собственном сайте.
С помощью такого простого поиска, вы сможете найти десятки уязвимостей типа Open Redirect в течение нескольких минут. В список уязвимых сайтов входят сайты банков, международных корпораций, доверенных компаний, любимых проектов и многочисленные сайты небольших организаций. В качестве дополнительного бонуса, каждый раз, когда поисковый робот Google будет натыкаться на сайты с Open Redirect, мы с помощью запросов будем получать обновленные результаты.
Лучший способ избежать уязвимости Open Redirect – это избегать перенаправления по параметру, зависящему от пользователя или приходящего через GET-запрос. Если перенаправление неизбежно, с ним можно совладать, проверив конечный сайт и очистив его репутацию с помощью белого списка подтвержденных URL-адресов.
Я бы посоветовал вам рассказать своим друзьям веб-разработчикам об Open Redirect. Вы можете переслать им эту статью или даже обнаружить уязвимости с помощью метода, упомянутого выше, и сообщить об этом компании с подробным описанием проблемы. Давайте вместе усложним проведение фишинговых атак!
Если вы хотите поделиться своими запросами в Google, которые работают для обнаружения Open Redirect, вы можете сделать это в комментариях.
You must be registered for see links



