ОРИГИНАЛЬНАЯ СТАТЬЯ
ПЕРЕВЕДЕНО СПЕЦИАЛЬНО ДЛЯ xss.pro
$600 на SSD для Jolah Molivski ---> 0x5B1f2Ac9cF5616D9d7F1819d1519912e85eb5C09 для поднятия ноды ETHEREUM и тестов
Введение
Представьте, что вы только что выбрали новую привлекательную программу вознаграждения за обнаружение ошибок, которую рекомендовал ваш друг, и вам не терпится попробовать ее из-за всех хороших историй, которые вы слышали, но после нескольких дней интенсивных исследований и й вы остались с пустыми руками. и закончить день без результатов. На следующий день вы начинаете сомневаться в себе, поэтому вы начинаете искать P4 и P5, как вдруг вы находите заголовок XSS. Кажется довольно шатким пока вы не вспомнили, что у вашей цели есть кеширующий сервер! Вы пытаетесь найти способ кэширования XSS для его хранения, но продолжаете застревать на MISS. Похоже, у них есть защита от отравления веб-кэша на этой конечной точке, что делает ее некэшируемой, так что вам не повезло. Как раз тогда, когда вы думали, что у вас есть P2 или P1, реальность УДАРЯЕТ вам, как полезная нагрузка веб-кэша Джеймса Кеттла. Это похоже на тупик, так что же теперь делать? Возможно, вы пробовали путаницу при синтаксическом анализе URL?
TL;DR
Введение
Представьте, что вы только что приобрели новую привлекательную программу по борьбе с ошибками, которую вам порекомендовал друг, и вам не терпится опробовать ее из-за всех хороших историй, которые вы слышали, но после нескольких дней интенсивной разведки и исследования вы остаетесь с пустыми руками и заканчиваете день без находок. На следующий день вы начинаете сомневаться в себе, поэтому начинаете искать P4s и P5s, как вдруг находите XSS заголовка. Казалось бы, ничего особенного, пока вы не вспомнили, что у вашей цели есть кэширующий сервер! Вы пытаетесь найти способ кэшировать XSS, чтобы сохранить его, но все время натыкаетесь на MISS. Похоже, что на этой конечной точке установлена защита от отравления веб-кэша, что делает ее недоступной для кэширования, так что вам не повезло. Как только вы подумали, что у вас есть P2 или P1, реальность поражает вас, как полезная нагрузка отравления веб-кэша Джеймса Кеттла. Это кажется тупиком, так что же делать дальше? Может быть, вы пробовали запутать парсинг URL?
TL;DR
Для любой страницы по пути https://www.glassdoor.com/Job/?xss все параметры URL отражаются в теге сценария Javascript. Отсутствие экранирования означает, что мы можем внедрить </script в страницу с https://www.glassdoor.com/Job/?xss=</script, однако из-за WAF мы не можем просто выйти из тегов сценария и выполнить свой собственный.
Значение куки optimizelyEndUserId отражается на странице сразу после параметров URL. Объединив это с проблемой из шага 1. мы можем обойти WAF, разделив полезную нагрузку на две части, чтобы выполнить произвольный javascript. Однако это самостоятельный XSS, поскольку мы не можем заставить нашу жертву отправить пользовательские cookies.
Мы можем обойти это с помощью отравления кэша. К сожалению, страницы под https://www.glassdoor.com/Job не кэшировались, но все страницы под https://www.glassdoor.com/Award/ кэшировались.
После некоторого тестирования я обнаружил, что символы обхода пути /.../, также известные как сегменты точек, нормализуются внешним кэширующим сервером, но не нормализуются внутренним веб-приложением (несогласие с RFC 3986 5.2.4). Это означает, что для пути https://www.glassdoor.com/Job/../Award/blah?xss=</script он будет восприниматься как https://www.glassdoor.com/Award/blah?xss=</script кэширующим сервером и кэшироваться, но содержимое https://www.glassdoor.com/Job/../Award/blah будет возвращено веб-сервером из-за отсутствия нормализации.
В результате, отправив запрос с нашей полезной нагрузкой на https://www.glassdoor.com/Job/../Award/blah?xss=</script (и остальной полезной нагрузкой в cookie), мы можем добиться успеха в реализации нашего XSS. Веб-сервер интерпретирует его как страницу под https://www.glassdoor.com/Job/ и вернет содержимое с нашей внедренной XSS полезной нагрузкой, а кэширующий сервер интерпретирует его как https://www.glassdoor.com/Award/blah?xss=</script, в результате чего ответ будет закеширован.
Затем, посетив страницу https://www.glassdoor.com/Award/blah?xss=</script, наш XSS сработает.
Достижение хранимого XSS было также возможно с помощью https://glassdoor.com/mz-survey/interview/collectQuestions_input.htm, который вел себя очень похоже на /Job, но XSS находился в заголовках и cookies, поэтому отправка параметра в URL была необязательна.
Отправка https://www.glassdoor.com/mz-survey/interview/collectQuestions_input.htm/../../../Award/blah с XSS в заголовках и файлах cookie приведет к сохраненному XSS под https://www.glassdoor.com/Award/blah.
Хранимый XSS PoC
Видео не на хостинге а на сайте не могу сюда залить смотрите с оригинала
Моя методология тестирования на XSS
При тестировании на XSS важно рассматривать все типы эксплойтов и обращать внимание на все, что выглядит интересно.
Даже если что-то не может быть использовано сейчас, постарайтесь увидеть потенциал этого в цепочке эксплойтов.
Часто цепочки эксплойтов состоят из неэксплойтных звеньев, которые сами по себе бесполезны, но при соединении в цепочку могут оказаться фатальными.
В Glassdoor я нашел такую конечную точку в /Job/new-york-ny-compliance-officer-jobs-SRCH_IL.0,11_IC1132348_KO12,42069.htm.
Я обнаружил, что имя параметра (и значение тоже) было отражено в ответе в несанированном виде.
Я был очень удивлен, увидев это, так как это должно было быть обнаружено очень рано. В программе Glassdoor почти 800 заявок, так что я не ошибся, думая, что я единственный, кто это заметил.
Параметр был отражен в строке в теге скрипта, поэтому для достижения XSS у меня было 2 варианта
- Вывести строку и внедрить javascript
- Закрыть тег скрипта и внедрить общую XSS полезную нагрузку.
Прежде чем пытаться играть против WAF, мы должны понять правила игры.Распространенная ошибка, которую я вижу, когда люди пытаются обойти WAF, или просто фильтры в целом, заключается в том, что они копируют и вставляют общие полезные нагрузки для обхода WAF, не понимая, почему WAF блокирует их запросы. По моему опыту, распылять и молиться WAF - это пустая трата времени, поэтому лучше протестировать их вручную, а главное - понять их. Поэтому мой первый шаг при обходе WAF - начать с заблокированной полезной нагрузки и удалять символ за символом, пока WAF не позволит мне пройти. К счастью, нам не потребовалось много времени, чтобы достичь соглашения с WAF. Все, что мне нужно было сделать, это удалить знак больше >, и я получил 200. Теперь вопрос в том, что еще ему не нравится? Похоже, что любой символ после </script привлечет внимание WAF, например, </scriptaaa. Это было бы большой проблемой, если бы WAF действительно блокировал </script*, но, к счастью, WAF разрешил пробельные символы, такие как %20 (пробел), что означает, что в конечном итоге тег скрипта закроется следующим приближающимся знаком больше >. Итак, следующим шагом будет поиск новой несанированной точки инъекции, которая позволит нам закрыть скрипт и внедрить HTML XSS полезную нагрузку. Я попытался посмотреть, могу ли я разбить полезную нагрузку на части с помощью других параметров, однако и это было заблокировано. Казалось, что правило WAF применяется ко всему URL, а не к отдельным параметрам. К счастью, я уже обходил такие типы WAF. Моей первой техникой goto было буквенно-цифровое загрязнение параметров HTTP, которое я уже использовал в прошлом для обхода аналогичного WAF в этой программе. Буквенно-цифровое загрязнение параметров злоупотребляет буквенно-цифровым порядком отраженных запросов, поэтому можно обойти подобный WAF, разбив вашу полезную нагрузку на различные параметры. К сожалению, в данном случае это оказалось не так, но я опубликую статью о том, как мне удалось использовать эту технику для достижения отраженного XSS. На этом этапе я потерял надежду на эту конечную точку, поэтому я решил поискать уязвимость в цепочке, а не отдельную уязвимость. В этот момент я начал просматривать файлы cookie.Тогда я заметил, что рядом с точкой инъекции в моем запросе было значение, полученное из cookie optimizelyEndUserId. Все, что мне нужно было сделать, это закрыть тег script и внедрить HTML. Инъекция ><svg> в cookie, похоже, помогла. Теперь мне нужно было выполнить javascript. Мы уже справились со сложной частью, так что теперь, когда мы смогли пронести тег svg мимо WAF, остальное должно быть просто. Довольно типичная полезная нагрузка для обхода WAF, похоже, справилась с задачей: ><svg/onload=a=self['aler'%2B't']%3Ba(document.domain)>. И теперь у нас есть XSS, который выглядит следующим образом:
Код:
GET /Job/new-york-ny-compliance-officer-jobs-SRCH_IL.0,11_IC1132348_KO12,42069.htm?attack=VULN%3C/script%20 HTTP/2
Host: www.glassdoor.com
Cookie: optimizelyEndUserId=BRUH><svg/onload=a=self['aler'%2B't']%3Ba(document.domain)>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Content-Length: 0Однако это самостоятельный XSS, который существует только в том случае, если мы имеем контроль над cookies.
Однако это может перерасти в отраженный XSS с отравлением кэша, так что это то, что я начал искать дальше (я знаю, что сказал хранимый XSS в описании, я обещаю, что мы скоро доберемся до этого!)
Методология поиска смягчения правил кэширования
При проведении первоначальной разведки мне всегда нравится тестировать кэш, чтобы посмотреть, как он себя ведет.
Если я вижу путь, который попадает в кэш, я всегда стараюсь проверить его предел. Многие веб-сайты имеют уникальные правила кэширования определенных путей и файлов, поэтому ручная проверка этих правил - отличный способ познакомиться с сервером кэша. Когда я начинаю вручную тестировать эти правила кэширования, я обычно сначала пытаюсь работать с расширениями. Я удаляю, добавляю или изменяю расширение и всегда внимательно слежу за заголовками кэширования и содержимым ответа. После того как я поработаю с расширением, я протестирую сам путь.Например, в Glassdoor я заметил, что https://www.glassdoor.com/Award/new...er-jobs-SRCH_IL.0,11_IC1132348_KO12,42069.htm кэшируется. Я перехватил запрос и отправил его в ретранслятор Burp для дальнейшей проверки.Когда я изменил расширение, я заметил, что хотя я получаю страницу 404, я все еще получаю заголовки кэша MISS/HIT. Это сразу натолкнуло меня на мысль, что существует некий шаблон для кэша или отсутствия кэша, вместо жестко закодированных файлов, которые кэшируются. Затем я перешел к пути. Я попробовал https://www.glassdoor.com/Award/somerandomfile и заметил, что он выдает мне ту же 404 страницу с теми же заголовками кэша. К тому времени я уже был уверен, что разобрался в правиле, но на всякий случай протестировал https://www.glassdoor.com/randompath/somerandomfile, который дал мне 404, но не кэшировался. Таким образом, теперь можно было предположить, что правило было /Award/*, что означало, что все, что находится по пути /Award, кэшировалось. Некоторое время я отчаянно пытался найти какой-нибудь XSS-заголовок, чтобы получить Web Cache Poisoning, но, к сожалению, я закончил с пустыми руками. Однако эта находка все равно оказалась для меня очень полезной. Хотя сама по себе она не является уязвимостью, это правило имело большой потенциал для объединения с уязвимостью.
Цепочка эксплойтов
Отравление веб-кэша может быть использовано для многих целей. Первые, которые приходят на ум: 1) Хранимый XSS 2) Эскалация неэксплуатируемого XSS в отраженный XSS 3) DoS.
На момент обнаружения правила кэширования я уже знал о неэксплуатируемой XSS в /Job/new-york-ny-compliance-officer-jobs-SRCH_IL.0,11_IC1132348_KO12,42069.htm?VULN%3C/script%20, поэтому попытка связать эти две ошибки в отраженную XSS-уязвимость показалась мне естественной.Я вернулся на "Рабочий путь", чтобы провести дополнительное исследование. Я хотел посмотреть, есть ли другие конечные точки, которые уязвимы к самостоятельному XSS, и они были. Я обнаружил, что каждая страница по пути Job была уязвима к self XSS, что было замечательно! Я сделал еще один шаг вперед и заметил, что даже страницы, которые должны были быть 404, на самом деле возвращали 200 и тоже были уязвимы для self XSS.
Итак, напомню важную информацию:
CDN имеет правило, которое кэширует /Award/*.
В /Job/* существует уязвимость self XSS.
Атакующая поверхность этих двух ошибок не была "статичной", а опиралась на шаблон подстановочных знаков, что заставило меня задуматься: "Действительно ли эти шаблоны будут принимать что-либо? Будет ли сервер отдавать предпочтение шаблону перед специальным синтаксисом URL, таким как сегмент с точкой /.../, или же он нормализует URL, а затем будет соответствовать шаблону?". Или другими словами: "Будут ли парсеры URL бэкенд-сервера и фронтенд-сервера нормализовывать сегменты точек?". Чтобы проверить это, я попробовал эти две полезные нагрузки с предположением, что парсер URL нормализует сегменты точек:
/Award/../this_should_not_cache
/Job/.../this_should_give_a_404
И к моему удивлению, они дали противоречивые результаты
Полезная нагрузка Award НЕ была кэширована, что означает, что парсер URL внешнего сервера нормализует сегмент с точкой перед сопоставлением с правилом кэширования. Однако путь к заданию вернул 200, что означает, что веб-сервер НЕ нормализовал сегмент точек. В заключение этого короткого теста можно сказать, что внешний и внутренний сервер разошлись во мнениях относительно того, как следует анализировать сегмент с точкой. Зная это, мы можем сконструировать следующую полезную нагрузку:
Код:
GET /Job/../Award/RANDOMPATHTATDOESNOTEXIST?cachebuster=046&attack=VULN%3C/script%20 HTTP/2
Host: www.glassdoor.com
Cookie: optimizelyEndUserId=BRUH><svg/onload=a=self['aler'%2B't']%3Ba(document.domain)>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Content-Length:Поскольку веб-сервер НЕ нормализует точечный сегмент, мы получим ответ с XSS.
Но поскольку фронтенд нормализует точечный сегмент, он будет кэширован (и сохранен) под /Award/RANDOMPATHTATDOESNOTEXIST?cachebuster=046&attack=VULN%3C/script%20
Теперь, когда жертва посетит сайт https://glassdoor.com/Award/RANDOMPATHTATDOESNOTEXIST?cachebuster=046&attack=VULN</script , она получит сохраненный ответ с XSS от CDN.
Хранимый XSS
Итак, как только я смог получить работающий PoC моего отраженного XSS, я сразу же сообщил об этом.
Однако я все еще не был достаточно удовлетворен, так как знал, что хранимый XSS должен был быть возможен при правильных условиях
Поэтому я продолжал искать XSS, который действительно был бы основан на заголовках и вел себя аналогично /Job/*, где XSS был возможен на каждой странице.
Тогда я вспомнил свой первый отчет в glassdoor, отраженный XSS в http://glassdoor.com/mz-survey/start_input.htm через загрязнение буквенно-цифрового упорядоченного параметра (в то время он все еще находился в стадии устранения, поэтому не был исправлен). Я подумал, что, возможно, мне удастся найти там же XSS для заголовка, и продолжил поиски. К счастью для меня, мой отраженный XSS из отчета также был уязвим для полного заголовочного XSS! Но он не вел себя так, как /Job/*, где каждая страница под ним была уязвима, поэтому он был практически бесполезен. Я вспомнил, что уязвимой была не только одна конечная точка, но и несколько других. К счастью, мне удалось найти конечную точку, которая была одновременно уязвима для header XSS и вела себя как /Job/* после тестирования каждой из уязвимых конечных точек, о которых я сообщал ранее, и я добрался до этой: https://glassdoor.com/mz-survey/interview/collectQuestions_input.htm/.
Полезная нагрузка выглядела примерно так:
Код:
GET /mz-survey/interview/collectQuestions_input.htm/.../.../.../Award/RANDOMPATHTATDOESNOTEXIST123?cachebuster=050 HTTP/2
Hоst: www.glassdoor.com
X-Forwarded-For: VULN
X-Forwarded-For: VULN><svg/onload=self[`alert`](document.domain)>
Cookie: gdId=VULN%22</script%20
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Из-за хитрой природы ошибки, процесс устранения был немного сложнее, чем обычно. Большое спасибо @bxmbn (AKA bombon на h1)) за помощь в процессе поиска.