Вопросы по уязвимостям - Страница 334

klanc · 27.11.2014, 21:32

Приветствую всех жителей форума! Есть тренировочная площадка от Acuentix для поиска уязвимостей в веб-приложениях (она так же указана в ссылках на OWASP'e).
На ней я нашел много всего, но пока особенно интересно место, где в поиске (слева сверху) можно вывести html код (я использовал следующий вариант: </h2><h1>test for html infection</h1><h2>).
Но при этом любой скриптовый код, будь он в тегах <script></script> или просто в атрибуте src какого-нибудь html тега, этот код удаляется при поиске.
Так вот у меня такой вопрос: потенциально возможно ли раскрутить до пассивной XSS или чего-то подобного?

ЗЫ понимаю, что все далеко нетупые, но скрин прилагаю для удобства.

Matthew · 27.11.2014, 21:37

Само приложение ничего не удаляет. Удаляет XSS Auditor в Chrome. Попробуйте в Firefox - должно работать.

klanc · 27.11.2014, 23:28

Цитата:

Сообщение от Matthew

Само приложение ничего не удаляет. Удаляет XSS Auditor в Chrome. Попробуйте в Firefox - должно работать.

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

klanc · 29.11.2014, 01:29

У меня возник такой вопрос по предыдущему сообщению: да, там в форме поиска выполняется произвольный JavaScirpt код, но как можно было бы этим воспользоваться в боевых условиях?
То есть какую вообще угрозу эта уязвимость представляет?
Просто там нет в адресной строке GET-параметров, через которые можно было бы получить ссылку на страницу, где выполняется поиск со скриптом в поисковой форме.

Matthew · 29.11.2014, 12:45

Всё просто. Жертва проходит по ссылке ведущей на страницу, контроллируемую злоумышленником, на которой следующий код:

Цитата:

<body onload=document.forms[0].submit()>
<form action="http://testphp.vulnweb.com/search.php?test=query" method="POST">
<input type="hidden" name="searchFor" value="<script>alert(8)</script>">
<input type="hidden" name="goButton" value="go">
</form>
</body>

Таким образом производится отправка post запроса от имени жертвы

klanc · 01.12.2014, 01:56

Matthew, спасибо за ответы.

Продолжаю тему по XSS...
Был найден еще один очень интересный случай: можно выполнить произвольный JavaScript код, но данную XSS непонятно, можно ли вообще эксплуатировать.
Что имеем:
Есть форма заполнения комментария, это форма обрабатывает HTML-код, то есть у меня хорошо выполнялся код <iframe onload=alert()></iframe> или <img src='#' onerror=alert() />, и после этого на странице с комментом была Stored XSS (или пассивная, как кому удобнее), но проблема в том, что этот коммент заносится не в БД на сервере, а в сессию, доступ к которой осуществляется через один параметр в cookie у пользователя, и хранится это сообщение/комментарий (с кодом) там в течении сессии, то есть там в той системе юзеры для себя комментируют/делают себе пометки.
Я стал разбираться, можно ли как-то сформировать ссылку, пройдя по которой пользователь оставит коммент с JS-кодом и соответственно выполнится этот код, но очередной барьер заключался в том, что при нажатии кнопки по добавлению коммента данные формы из поля для текста коммента отправляются не посредством обычного POST запроса и вообще не через атрибут action, а через аттрибут onclick на кнопке, там вызывается JS функция:

Цитата:

Ссылки на страницу дать, к сожалению, не могу из-за правил форума/темы, но приведу листинг кода этой функции:

Цитата:

Три функции show(), hide() и empty() – это, как многие догадались, функции jQuery.
Тут мы видимо, что эта функция формирует Ajax запрос методом POST, в котором передает параметры, куки, один из которых играет ключевую роль (ниже опишу) и наш коммент.
Итак заголовки запроса:

Цитата:

Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Cache-Control no-cache
Connection keep-alive
Content-Length 123
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Cookie h_p=881a75edd1d32c20f3dee5a94452f1c3; complaint=622d9f9dea075b994d3c2f60867a5db3; first=1417367988; __utma=63792317.339146785.1417367991.1417371990.14 17384115.3; __utmz=63792317.1417367991.1.1.utmcsr=(direct)|utm ccn=(direct)|utmcmd=(none); PHPSESSID=7apd9n3llr0njrk366gbah0lb3; __utmb=63792317.4.9.1417384164174; __utmc=63792317; _ym_visorc_67132=w
Host www.cian.ru
Pragma no-cache
Referer http://www.cian.ru/cat.php?deal_type=1&obl_id=1&city[0]=1
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0

Параметры (тело запроса):

Цитата:

mode=save&deal_type=rent&offer_type=flat&oid=12081 370&text=%253Ciframe%2520onload%253Dalert%28%29%253E%253C%2 52Fiframe%253E

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

Это все сведения, которые нарыл, и от которых надо отталкиваться.
В принципе можно написать PHP или JS-скрипт, который отправляет Ajax-запрос, как это делается в той функции note_save(), устанавливает там текст коммента, свое значение complaint для кук, и после этого перенаправляет на нужную страницу с комментом.
Но потом проблема будет в том, что это, установленное скриптом, значение complaint на сервере, не совпадет со значением из кук юзера, которого перенаправили, ведь сайт ему когда-то присвоил свое значения или сайт установит новое значение, которое так же не будет совпадать с нашим.
НО это сайт будет присваивать свое значение, если мы просто перенаправим пользователя, А ЕСЛИ мы это сделаем через GET-запрос, где в параметре Cookie отправим свое значение complaint (как будто от пользователя из кук), то получается, что мы как бы обойдем стороной старые куки юзера (если они есть) или в случае их отсутствия скажем сайту, что они типа есть (ведь в запросе их указали).

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

Matthew · 01.12.2014, 22:31

Я ничего не понял (и не удивительно, ведь предпоследний абзац это одно(!) предложение), но судя по всему запрос на сохранение этой "заметки" не обладает никаким CSRF-токеном, если параметр oid им не является. Так вот, если oid действительно но является CSRF токеном то мы так же можем сохранить свой пейлоад в сессии пользователя через POST запрос, как я показывал ранее.

klanc · 02.12.2014, 00:18

Цитата:

Сообщение от Matthew

Я ничего не понял (и не удивительно, ведь предпоследний абзац это одно(!) предложение), но судя по всему запрос на сохранение этой "заметки" не обладает никаким CSRF-токеном, если параметр oid им не является. Так вот, если oid действительно но является CSRF токеном то мы так же можем сохранить свой пейлоад в сессии пользователя через POST запрос, как я показывал ранее.

Прошу пощения, что так запутанно написал (я немного подкорректировал). Я еще не пробовал реализовать ту схему, завтра попробую на интерес. Да, oid – не CSRF токен, id поста, к которому пишется коммент.
Попробую описать более просто и без лишних деталей.
Вобщем там ситуация такая: на сервере с помощью определенного POST запроса можно временно сохранить текст комментария вместе со значением complaint. С помощью этого значения (complaint) сервер потом определяет, можно ли показывать пользователю коммент, то есть когда пользователь запрашивает страницу с постом, он ведь отправляет серверу свои куки, в которых есть это значение, сервер по этому значению ищет у себя комменты и отображает их (если они есть).
Поэтому идея заключается, что можно сначала установить через POST-запрос коммент с кодом и вместе с определенным значением complaint для этого коммента, затем через метод GET запросить страницу с постом, к которому был добавлен коммент с кодом, в этом запросе в параметре COOKIE передать наше установленное до этого значение complaint, поэтому сервер должен будет вернуть страницу с комментом, где выполнится наш код.

Я понял, что вы имели ввиду, только возник такой вопрос: ведь когда мы сохраняем плейлоад в сессии через активацию формы (как вы до этого приводили пример), то браузер автоматически перенаправляет пользователся на эту страницу, к которой идет POST-запрос, а можно ли этого (перенаправления) как-то избежать?
Просто плейлоад загружается POST-запросом на одну страницу, а коммент отображается на другой. Поэтому я сначала думаю просто сделать POST-запрос в ту страницу, куда код заливается, а потом уже редирект на другую, но может быть подобное можно сделать через форму.

Matthew · 02.12.2014, 11:32

Можно сделать POST запрос в скрытом iframe. Вот пример кода:

Цитата:

<body onload=document.forms[0].submit()>
<iframe name="payload" style="display:none"></iframe>
<form action="http://testphp.vulnweb.com/search.php?test=query" method="POST" target="payload">
<input type="hidden" name="searchFor" value="<script>alert(8)</script>">
<input type="hidden" name="goButton" value="go">
</form>
</body>

После этого можно уже делать редирект на страницу где пейлоад выполнится

klanc · 02.12.2014, 21:10

Вобщем я попробовал, оба способа работают, ваш только покороче и поудобнее в плане реализации получается, спасибо.

27.11.2014, 21:32	#3331
klanc Регистрация: 27.11.2014 Сообщений: 8 Репутация: -1	Приветствую всех жителей форума! Есть тренировочная площадка от Acuentix для поиска уязвимостей в веб-приложениях (она так же указана в ссылках на OWASP'e). На ней я нашел много всего, но пока особенно интересно место, где в поиске (слева сверху) можно вывести html код (я использовал следующий вариант: </h2><h1>test for html infection</h1><h2>). Но при этом любой скриптовый код, будь он в тегах <script></script> или просто в атрибуте src какого-нибудь html тега, этот код удаляется при поиске. Так вот у меня такой вопрос: потенциально возможно ли раскрутить до пассивной XSS или чего-то подобного? ЗЫ понимаю, что все далеко нетупые, но скрин прилагаю для удобства. Последний раз редактировалось klanc; 27.11.2014 в 23:26..

Опции темы	Поиск в этой теме
Версия для печати Отправить по электронной почте	Поиск в этой теме: Расширенный поиск
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид

27.11.2014, 21:37	#3332
Matthew Регистрация: 14.06.2011 Сообщений: 35 Репутация: 3	Само приложение ничего не удаляет. Удаляет XSS Auditor в Chrome. Попробуйте в Firefox - должно работать.

29.11.2014, 01:29	#3334
klanc Регистрация: 27.11.2014 Сообщений: 8 Репутация: -1	У меня возник такой вопрос по предыдущему сообщению: да, там в форме поиска выполняется произвольный JavaScirpt код, но как можно было бы этим воспользоваться в боевых условиях? То есть какую вообще угрозу эта уязвимость представляет? Просто там нет в адресной строке GET-параметров, через которые можно было бы получить ссылку на страницу, где выполняется поиск со скриптом в поисковой форме.

01.12.2014, 22:31	#3337
Matthew Регистрация: 14.06.2011 Сообщений: 35 Репутация: 3	Я ничего не понял (и не удивительно, ведь предпоследний абзац это одно(!) предложение), но судя по всему запрос на сохранение этой "заметки" не обладает никаким CSRF-токеном, если параметр oid им не является. Так вот, если oid действительно но является CSRF токеном то мы так же можем сохранить свой пейлоад в сессии пользователя через POST запрос, как я показывал ранее.

02.12.2014, 21:10	#3340
klanc Регистрация: 27.11.2014 Сообщений: 8 Репутация: -1	Вобщем я попробовал, оба способа работают, ваш только покороче и поудобнее в плане реализации получается, спасибо.