Эффективный поиск XSS-уязвимостей19.08.2021 19:31

Про XSS-уязвимости известно давным-давно — казалось бы, нужен ли миру ещё один материал о них? Но когда Иван Румак, занимающийся тестированием безопасности, поделился методологией их поиска на нашей конференции Heisenbug, реакция зрителей оказалась очень положительной.

И спустя два года у этого доклада по-прежнему растут просмотры и лайки, это один из самых востребованных материалов Heisenbug. Поэтому теперь мы решили, что многим будет полезна текстовая версия, и сделали ее для Хабра.

Под катом — и текст, и видео. Далее повествование идет от лица Ивана.

Обо мне

Я занимаюсь тестированием безопасности. По сути, занимаюсь всеми вопросами, связанными с безопасностью сайтов. Параллельно участвую в разных Bug Bounty, занимаю 110 место на платформе HackerOne, нахожу баги в Mail.ru, Яндексе, Google, Yahoo! и других крупных компаниях. Обучаю, консультирую, рассказываю про безопасность в вебе и не только.

История доклада

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

Что такое XSS? Как искать? Как понимать, есть XSS или нет? Сейчас разберемся.

План

Что такое XSS-уязвимости
Методология поиска XSS (которой пользуюсь сам и с помощью которой нашел более 60 XSS в Bug Bounty за последний год)
Какую проверочную строку (пейлоад) использовать для поиска XSS-уязвимостей
Кейсы из разных Bug Bounty-программ (какие XSS были, как их можно найти, и баги, которые по методологии поиска похожи на поиск XSS)

Зачем искать уязвимости?

Вам — полезный навык, который никогда не будет лишним. Компании, где вы работаете — дополнительная безопасность. Win-win!

Что такое XSS

XSS (Cross-Site Scripting) — возможность выполнения произвольного JavaScript-кода в браузере жертвы в контексте вашего сайта.

Вспомним, как вызывается JavaScript из HTML:

— всё, что внутри, будет срендерено браузером как JavaScript.

test — можно использовать обработчики событий, то есть атрибут, например, onerror. Браузер попробует подгрузить картинку по источнику x. Если картинка не прогрузится, он выполнит то, что указано в обработчике событий.

click to trigger javascript — если гиперссылка ведет не на схему HTTP/HTTPS, а начинается со схемы JavaScript, то при нажатии на ссылку всё, что после схемы JavaScript, будет срендерено как JavaScript.

</code></strong> — то же самое, что и с гиперссылкой, только ничего не надо кликать, сработает при прогрузке.</p> <p>XSS — одна из самых распространенных уязвимостей в вебе. К XSS уязвимо более 95% веб-приложений. Чтобы найти баг, не обязательно обладать специальными навыками, проходить курсы или получать высшее образование. </p> <p>И действительно, несмотря на то, что XSS — распространенная уязвимость, она остается одной из самых серьезных клиентских уязвимостей.</p> <p><br /></p> <h2>Причины возникновения XSS</h2> <p>Во-первых, XSS возникает при генерации HTML-страницы, когда разработчику нужно поместить туда указанные пользователем данные (ФИО, организация). Если разработчик записал данные в БД, затем тянет ее в HTML-шаблон, то это stored (сохраненный) XSS.</p> <p>Разработчику могут понадобиться параметры из URL или тела запроса. Такой тип XSS называется reflected.</p> <p>Причин XSS куча, потому что есть динамические изменения страницы с помощью JS, есть события, которые постоянно происходят на клиентской стороне с JS.</p> <p>Но в этом докладе я расскажу про самые распространенные типы — stored XSS и reflected XSS. </p> <p>Возьмем пример — обычная страница ВКонтакте. О чем подумает человек, который хочет найти XSS-уязвимости? </p> <p>Во-первых, он обратит внимание на то, что есть поля, можно куда-то зарегистрироваться и что-то ввести. </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Попробуем ввести туда честные данные, но при этом добавим к ним <code><script></script></code>. Он нужен для вызова JavaScript между открывающим и закрывающим тегами. </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Что произойдет в этом случае? </p> <p>Мы, как пользователь, который хочет зарегистрироваться во ВКонтакте, заливаем ему наши проверочные строки. Дальше разработчик сохраняет их в базу данных, и с этими данными ему надо работать. Нужно показывать их пользователю на его странице, в личных сообщениях и много где еще. Дальше данные попадают пользователю в браузер, когда они возвращаются ему обратно. </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Допустим, разработчик не подумал, что в качестве имени пользователя могут быть не только честные данные, а еще и HTML-теги, которые встраиваются в оригинальный HTML-шаблон. Браузеру пофиг, он рендерит все, что ему сказал разработчик, поэтому рендерится и строка.</p> <p>Оно могло бы выстрелить где-нибудь здесь: </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Конечно, во ВКонтакте такой уязвимости нет. Но, так как эта страница является публично доступной, любой в интернете может на нее зайти, то это была бы довольно серьезная уязвимость. </p> <p>Но вообще мы, как тестировщики, которые ищут XSS-уязвимости, чаще всего делаем это блэкбоксом. Мы не знаем, что происходит на сервере, какая база данных там используется, делает ли разработчик что-то с этими данными. Всё, что у нас есть, — это поле, куда мы можем что-то ввести, и какие-то страницы, куда это потом возвращается. </p> <p>Методология поиска XSS, которую я сейчас вам покажу, основана как раз на том, что мы не знаем, какие процессы происходят на сервере. </p> <p><br /></p> <h2>XSS-методология</h2> <p><br /></p> <ol><li><p>Помещаем пейлоад (проверочную строку, призванную выявлять уязвимости) во все поля и параметры.</p><br /></li> <li><p>Смотрим в DOM на предмет санитизации. </p><br /></li> <li><p>Рано или поздно спецсимволы не перекодируются, или выполнится функция alert.</p><br /></li> <li><p>Раскручиваем дальше или репортим, как есть.</p><br /></li> </ol> <p>Еще один пример — страница поиска. В поле поиска попробуем ввести «qweqwe». </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Поищем это в DOM: </p> <p>F12 → Ctrl +F → «qweqwe»</p> <p>Мы видим, что строка «qweqwe» попала из поля для поисков в параметр query. И она попала в страницу 17 раз. То есть у нас есть 17 потенциальных мест, где разработчик может не подумать о выводе этой строки пользователю в браузер, и может возникнуть XSS-уязвимость.</p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Конечно, «qweqwe» недостаточно, чтобы выявить XSS-уязвимость, мы добавим туда спецсимволы: </p> <p>Input: qweqwe <strong>' » > <</strong></p> <p>Посмотрим, что выведется в DOM: </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Спецсимволы превратились в закодированный кусок символов. Это уже сигнализирует, что есть санитизация, возможно, неосознанная. </p> <p>Но в девятом месте, где наша строка встраивается в DOM, спецсимволы на первый взгляд не перекодировались, то есть они отображаются здесь как есть.</p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Но если мы попробуем отредактировать это как HTML, то увидим, что двойная кавычка превратилась в <code>&quot</code>.</p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Это называется <strong>HTML entities</strong>. Особенность использования браузером этой кодировки заключается в том, что браузер рисует соответствующий символ на странице, но HTML-теги, состоящие из этих символов, не рендерятся браузером как код: </p> <pre><code class="plaintext">‘ — ' " — " > — > < — < & — &amp</code></pre> <p>Это выглядит вот так: </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Слева у нас HTML-код, который должен отрендерить браузер, но он просто показывает его как строку.</p> <p><strong>Санитизация</strong> — преобразование определенных символов пользовательской строки в соответствующие HTML entities или другую кодировку.</p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Другими словами, у нас есть набор потенциально опасных символов, которые мы хотим санитизировать. Мы хотим их превратить в HTML entities, чтобы они не встраивались в наш изначальный шаблон, который мы хотим исполнять на пользователя, и нельзя было протолкнуть чужой JS.</p> <p>Вернемся к этому примеру. Двойная кавычка заинкодилась в &quot, получается, санитизация есть. </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>А если бы не было? Мы попробуем ввести » » test, и поищем по строке «qweqwe»: </p> <p>Input: qweqwe <strong>' » test</strong></p> <p>F12 → Ctrl +F → «qweqwe»</p> <p>Что мы увидим? </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Мы увидим, что test начал подсвечиваться коричневым. Браузеры помогают нам: они подсвечивают атрибуты, значения атрибутов и названия тегов разными цветами. Атрибуты всегда коричневые, имена тегов — розовые, значения параметров — синие. </p> <p>Если бы вся строка была синяя, мы могли бы сразу понять, что она попала внутрь значения атрибута, и можно было бы сделать вывод, что XSS нет. </p> <p>Но здесь предположим, что она есть, и у нас записался атрибут test. И если мы вместо этого атрибута используем обработчик событий, например: </p> <p>Input: qweqwe <strong>' » onfocus='alert ()' autofocus</strong></p> <p>Получаем reflected XSS: </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Это сложно, поэтому я предложу решение в виде <strong>универсального пейлоада</strong> — это строка, которая должна выявлять XSS в разных контекстах и которая не требует дополнительного раскручивания в таких местах.</p> <p><br /></p> <h3>XSS — Level 0</h3> <p>Начнем с самой простой строки, на которую натыкались все, кто когда-то интересовался тестированием безопасности: </p> <p><code><script>alert()</script></code></p> <p>Посмотрим на примере языка PHP, когда я как разработчик хочу выводить пользователю HTML-код и подтягиваю туда значение параметра, в нашем случае — name: </p> <pre><code class="php"><p> Привет, <?php echo($_GET["name"]); ?>! </p></code></pre> <p>Функция echo () в PHP не делает санитизацию, она выводит всё как есть. То есть это типичная reflected XSS-уязвимость. И если мы поместим в параметр name на этой странице наш текущий пейлоад, он срендерится браузером, потому что никакой санитизации нет. Он встраивается как есть, браузер не отличает пользовательскую строку от оригинальной и рендерит.</p> <p><code>/page.php?name=<script>alert()</script></code></p> <pre><code class="php"><p> Привет, <script>alert()</script>! </p> </code></pre> <p>То же самое, если разработчик не берет параметр из URL, а берет из базы данных данные, которые когда-то вводил пользователь: </p> <pre><code class="php"><p> Привет, <?php $sql=…; echo($sql); ?>! </p> <p> Привет, Вася<script>alert()</script>! </p></code></pre> <p>Вот пример посложнее: </p> <pre><code class="php"><form action="page.php" method="POST"> <input name="name" value="<?php echo($_GET["name"]); ?>"> </form></code></pre> <p>Что, если мне надо брать значение параметра и отображать его внутри значения атрибута? Как меня могут хакнуть в этом случае? </p> <pre><code class="php"><form action="page.php" method="POST"> <input name="name" value="<script>alert()</script>"> </form></code></pre> <p>Если мы поместим туда наш <code><script>alert()</script></code>, разумеется, это не сработает. Даже если нет санитизации и вставка небезопасна, то <code><script>alert()</script></code> просто не выявит эту XSS-уязвимость, потому что нужно закрыть атрибут. </p> <p>Мы закроем не только атрибут, но еще и тег <code><input></code>, куда мы попали, и встроим свой <code><script>alert()</script></code>, который отрендерится браузером: </p> <p><code>/page.php?name="><script>alert()</script></code></p> <pre><code class="php"><form action="page.php" method="POST"> <input name="name" value=""><script>alert()</script>"> </form></code></pre> <p>И раз мы знаем, что есть кейсы, когда мы можем попасть внутрь значения атрибута, почему бы нам сразу не добавить <code>"></code> в пейлоад? </p> <p><br /></p> <h3>XSS — Level 1</h3> <p>А если мне надо подставить пользовательское значение внутрь <code><title></code>? Подставим туда наш текущий пейлоад: </p> <pre><code class="xml"><html> <head> <title>Привет,"><script>alert()</script></title> </head> <body> <script type="text/javascript" src="/assets/jquery.min.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/jquery/jquery.json.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/jquery/jquery.form.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/jquery/jquery.easing.1.2.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/jquery/effects.core.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/js/browser-sniff.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/js/scripts.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/js/pcnews-utils.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/js/pcnews-auth.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/js/pcnews-fiximg.js"></script> <script type="text/javascript" src="/assets/a70a9c7f/js/pcnews-infobox.js"></script> </body> </html></code></pre> <p>Это не сработает, потому что тег <code><title></code> нужен браузеру, чтобы отображать имя текущей вкладки. Браузер думает, что раз это всего лишь название вкладки, ему незачем рендерить значение этого тега, и он просто будет рендерить всё как текст. </p> <p>Здесь нужно добавить <code></title></code> перед нашим вредоносным <code><script>alert()</script></code>. </p> <p><code>/page.php?name="></title><script>alert()</script></code></p> <pre><code class="xml"><html> <head> <title>Привет,"></title><script>alert()</script> </title> </head> <body> </body> </html></code></pre> <p>Таким образом мы закроем оригинальный <code><title></code>. </p> <p>Раз мы знаем, что разработчик может подтянуть наши значения еще и внутрь тега <code><title></code>, почему бы сразу не добавить его в пейлоад и не вставлять этот пейлоад везде? Так мы попадаем сразу в несколько ситуаций. </p> <p>Вроде звучит здорово, но если мы попали внутрь тега <code><script></code>: </p> <pre><code class="php"><script> var name="<?php echo($_GET["name"]); ?>"; </script> </code></pre> <p>Разработчик написал JavaScript, внедрил его у себя на страницу, но какую-то переменную берет из пользовательского значения. Поместим туда наш текущий пейлоад: </p> <p><code>/page.php?name="></title><script>alert()</script></code></p> <pre><code class="php"><script> var name=""></title><script>alert()</script>"; </script> </code></pre> <p>Всё не отработает до момента, когда мы закрыли <code></script></code>.</p> <p>Здесь все тоже достаточно тривиально, просто закрываем тег разработчика <code><script></code>: </p> <p><code>/page.php?name="></script></title><script>alert()</script></code></p> <pre><code class="php"><script> var name=""></script></title><script>alert()</script>"; </script></code></pre> <p>Я не буду дальше мучить вас каждым таким тегом. </p> <p>На самом деле, надо закрывать еще и <code></style></code>, и <code></noscript>,</code> и <code></textarea></code>, значения которых рендерятся браузером как строка.</p> <p><br /></p> <h3>XSS — Level 2</h3> <p>Помните, мы попадали внутрь значения атрибута, закрывали его, открывали <code><script>alert()</script></code>, чтобы выполнить функцию <code>alert ()</code>, и мы использовали там двойную кавычку: </p> <pre><code class="php"><form action="page.php" method="POST"> <input name="name" value="<?php echo($_GET["name"]); ?>"> </form></code></pre> <p>А мог ли разработчик обособлять все одинарными кавычками? Браузер это принимает, это вполне нормальное поведение. И если бы мы поместили туда наш текущий пейлоад, разумеется, он бы не сработал: он бы не обнаружил эту XSS-уязвимость, потому что мы закрываем двойную кавычку.</p> <p><code>/page.php?name="></script></title><script>alert()</script></code></p> <pre><code class="php"><form action='page.php' method='POST'> <input name='name' value='"></title></script><script>alert()</script>'> </form></code></pre> <p>Здесь тоже все просто: достаточно добавить одинарную кавычку перед двойной, и мы закроем и этот кейс. </p> <p><code><?php $a = str_replace('>', '>', $_GET["name"]); ?></code></p> <pre><code class="php"><form action='page.php' method='POST'> <input name='name' value='<?php echo($a) ?>'>! </form></code></pre> <p>А вот если разработчик подумал: «Я допускаю, что пользователь может использовать кавычки, но главное, что он не закрывает мой <code><input></code> и не открывает теги вроде <code><script>alert()</script></code>. Тогда я буду просто энкодить закрывающую угловую скобку, чтобы он не смог закрыть мой <code><input></code>».</p> <p>Но если мы действительно попробуем закрыть <code><input></code> и открыть <code><script>alert()</script></code>, то ничего не сработает: </p> <p><code>/page.php?name='><script>alert()</script></code></p> <pre><code class="php"><form action='page.php' method='POST'> <input name='name' value=''><script>alert()</script>'>! </form></code></pre> <p>Здесь достаточно использовать обработчики событий: </p> <p><code>/page.php?name='%20autofocus%20onfocus='alert();</code></p> <pre><code class="php"><form action='page.php' method='POST'> <input name='name' value='' autofocus onfocus='alert();'>! </form></code></pre> <p>Возможность писать свои атрибуты уже дает нам гарантированную XSS-уязвимость.</p> <p>Когда мы попадали внутрь <code><script></code>, то закрывали его, открывали свой <code><script></code> и делали что-то внутри. А могли бы мы продолжить писать JS внутри JS, который написал разработчик? То есть продолжить его код, стараясь не вызвать синтаксическую ошибку. Да, могли бы: </p> <p><code>/page.php?name=";+alert();//</code></p> <pre><code class="php"><script> var name=""; alert();//"; </script></code></pre> <p>Есть еще случай, когда разработчику надо подставлять параметры внутрь гиперссылки: </p> <p><code><a href="<?php echo($_GET["returnUrl"]); ?>">Вернуться</a></code></p> <p>Цель — редиректнуть пользователя туда, откуда он пришел. Например, пользователь пришел в приложение. Оно редиректит его на аутентификационный поддомен, и когда он аутентифицировался, этот поддомен должен редиректнуть его обратно в приложение. </p> <p>Можно вызывать JS в гиперссылках, в том числе при редиректах, если использовать схему JS: </p> <p><code>/page.php?returnUrl=javascript:alert()</code></p> <p><code><a href="javascript:alert()">Вернуться</a></code></p> <p>При нажатии на «Вернуться» сработает функция <code>alert()</code>. </p> <p>Если поставить перед javascript пробел, то это тоже сработает: </p> <p><code>/page.php?returnUrl=%20javascript:alert()</code></p> <p><code><a href=" javascript:alert()">Вернуться</a></code></p> <p>Сработает не только %20 (пробел), но и %09 (табуляция).</p> <p>Я покажу в качестве примера XSS, который я нашел на поддомене Mail.ru, — biz.mail.ru.</p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>У них было приложение. Если вы получали на странице ошибку 500, вас редиректит на страницу с ошибкой 500 и кнопкой «Обновить». При этом передается параметр <code>from</code>. Это нужно затем, чтобы, когда пользователь перешел на страницу с ошибкой, он мог нажать кнопку «Обновить» и вернуться туда, где у него возникла ошибка (вдруг она была единичная). </p> <p>Там передавался полный путь до страницы, и я попробовал вписать туда <code>javascript:alert()</code>. Но если строка начинается со слова <code>javascript</code>, то туда просто подставляется дефолтное значение HTTPS без mail.ru.</p> <p>Но если поставить пробел (%20) перед словом <code>javascript</code>, регулярка Mail.ru не обрабатывает этот случай и, вполне возможно, выполняет произвольный JavaScript-код на поддомене Mail.ru.</p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Сценарий атаки: я бы просто скинул ссылку на эту ошибку 500 другому пользователю. И если бы он нажал кнопку «Обновить», у него бы сработал JS, который я захотел. </p> <p>Подумаем, как разработчик вообще мог починить такую уязвимость. В случае с XSS мы можем просто санитизировать пользовательские специальные символы. Но в случае со схемой JavaScript это не сработает, потому что здесь немного другие символы. </p> <p>Разработчик может подумать: «А что, если я буду требовать формат URL в том же параметре <code>from</code>?»</p> <p>protocol://host: port/…</p> <p>Используя синтаксис JavaScript, можно сделать пейлоад, который выглядит как URL, но также вызывает функцию <code>alert()</code> при нажатии: </p> <p><code><a href="javascript://qwe.com/%0aalert()">Вернуться</a></code></p> <p>Мы вызываем single line comment, комментим всё до переноса строки, переносим строку и выполняем наш <code>alert()</code>. Можно сконструировать такой пейлоад.</p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>А это сработает, если запретить слово javascript в URL? </p> <p>Как нам уже известно про HTML entity, браузер в некоторых местах использует эту кодировку неоднозначно. Если слово javascript: заэнкожено в HTML entity, при нажатии на эту ссылку браузер всё равно поймет, что HTML entity — это схема JavaScript, её тоже можно использовать. </p> <pre><code class="javascript"><a href="javascri&#x7 0;t&colon;//qwe.com/%0aalert()">Вернуться</a> javascript&colon; = javascript: </code></pre> <p>Таким образом мы обойдем защиту, если бы она была.</p> <p>Единственный правильный способ здесь — это требовать, чтобы ссылка начиналась на http (s) или была относительной.</p> <p><br /></p> <h3>XSS — Level 3</h3> <p>Наш пейлоад довольно большой и попадает в несколько кейсов: </p> <p><code>'"></title></script><script>alert()</script></code></p> <p>Мне не нравится, что мы вроде делаем крутой пейлоад, а используем <code><script>alert()</script></code> — самую нубскую вещь, которую можно найти в начале поиска XSS-уязвимостей. </p> <p>Я предлагаю использовать iframe с обработчиком событий: </p> <p><code>'"></title></script><iframe onload='alert``'></code></p> <p><code><iframe></code> — тег для отображения страницы внутри страницы. Допустим, вы находитесь на каком-нибудь сайте и, если сайт хочет подгрузить в себя еще один сайт, то разработчик использует этот тег. Также там есть атрибут <code>src</code> — адрес до сайта, который он хочет показать у себя. И независимо от того, прогрузился путь или нет, <code>onload</code> будет работать всегда. </p> <p><strong>Плюсы iframe: </strong></p> <p><br /></p> <ul><li><p>Легко заметить, если пейлоад встраивается в страницу, но на onload работают санитайзеры.</p><br /></li> <li><p>Есть волшебный аттрибут <code>srcdoc</code>: </p><br /></li> </ul> <p><code><iframe srcdoc="<script>alert()</script>"></code></p> <p>Разработчики используют iframe на всяких форумах, дают возможность пользователю помещать его на сайт, но если они не подумали про этот атрибут, то возможно выполнение произвольного JS. </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Здесь в качестве значения атрибута <code>srcdoc</code> используется просто HTML entity: </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p><br /></p> <ul><li>Не раскрутить XSS — есть почти гарантированный open redirect.</li> </ul> <p>Если у вас не получилось раскрутить XSS, например, разработчик решил, что хочет разрешить встраивать пользовательский iframe, но без обработчиков событий и без srcdoc, то у нас всё равно есть уязвимость другого типа — <strong>open redirect</strong>, пейлоад которого выглядит так: </p> <p><code><iframe width="648" height="365" src="https://avtohanter.ru/toplevel.html"></code></p> <p>У нас есть iframe, его src указан на другую страницу в интернете, подконтрольную злоумышленнику. Содержимое этой страницы довольно простое — всего лишь скрипт, который задает top.window.location на другую страницу.</p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>И если браузер срендерит это на каком-то сайте, произойдет редирект на https://evil.com. </p> <p>У браузера есть иерархия окон, есть окно верхнего уровня и промежуточные окна. И iframe, который подгружается внутри сайта, является промежуточным окном, но при этом он может влиять на окно верхнего уровня. Он может переписать его top.window.location, и возникает уязвимость open redirect.</p> <p>Лечится это атрибутом sandbox, но никто об этом не задумывается. Если есть разрешение устраивать пользовательский iframe, то таким пейлоадом можно редиректить других пользователей куда угодно.</p> <p><br /></p> <h3>XSS — Level 1337</h3> <p>Перейдем на суперхакерский уровень XSS-уязвимостей: </p> <p><br /></p> <ul><li>Пробелы между атрибутами в теге могут замениться слэшем. Тег необязательно закрывать! </li> </ul> <p><code><iframe/onload='alert()'</code></p> <p><br /></p> <ul><li>Браузеры закрывают теги за разработчиков. </li> </ul> <p>Таким образом, исходя из этих двух фактов, мы можем прийти от такого пейлоада: </p> <p><code>'"></title></script><iframe onload='alert``'></code></p> <p>К такому: </p> <p><code>'"></title/</script/</style/><iframe/onload='alert``'</code></p> <p>Поменяли все пробелы на слэш и убрали закрывающую скобку у iframe. Есть кейс, когда пейлоад попадает внутрь комментария <code>()</code>, нужно сразу закрыть его.</p> <p><code>'"></title/</script/</style/--><iframe/onload='alert``'</code></p> <p>Покажу еще один пример из Bug Bounty, он из приватной программы. Это XSS-уязвимость в личных сообщениях. Разработчики обрезали всё, что подходит под паттерн »<…>», чтобы защититься от XSS-уязвимостей. Если пошлем закрытый тег, он обрежется: </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Однако, если мы пошлем незакрытый тег, то он отрендерится: </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p><br /></p> <h2>Фреймворки</h2> <p>Также есть разные фреймворки, например, клиентские AngularJS и VueJS. </p> <p>Здесь тоже есть специфический пейлоад: </p> <p>{{7×7}} --> 49</p> <p>Если это посчиталось на клиентской стороне и превратилось в 49, то здесь тоже возможна XSS-уязвимость. Нужно использовать constructor.constructor и вызвать alert: </p> <p><img src="https://habr.com/img/image-loader.svg" alt="image-loader.svg" /></p> <p>Пейлоад, конечно, зависит от версии AngularJS, поэтому нужно чекнуть версию и подобрать пейлоад из списка.</p> <p>Как и в случае с прошлыми примерами HTML entity, для AngularJS не имеет значения, используются ли фигурные скобки или HTML entities. Если разработчик подумал: «Я использую AngularJS или VueJS и не хочу, чтобы мне вставляли фигурные скобки, буду их обрезать», то достаточно поместить HTML entity-представление, и браузер уже срендерит это как надо. </p> <p>{{7×7}} → 49</p> <p>У VueJS пейлоад тот же самый. </p> <p>Вот такой пейлоад получился: </p> <p>'»/test/></title/</script/</style/-->{{7×7}}<iframe/onload='alert``'… — ситуативно</p> <p>'»/test/ — если можем записать свой атрибут (onerror, onmouseover, …)</p> <p>{{7×7}} — AngularJS, VueJS</p> <p>Этот пейлоад не покрывает случаи, когда мы попали внутрь тега <code><script>alert()</script></code>, и нам нужно не закрыть этот тег, а продолжать писать валидный JS (то есть без синтаксических ошибок). Если вы попали в функцию внутри функции внутри объекта, то вам нужно закрыть определенное количество фигурных скобок, нужно смотреть контекст. Универсального решения нет.</p> <p>Но ведь есть много полиглот-пейлоадов. В чем отличия? </p> <p><br /></p> <ul><li><p>размер строки меньше, т. к. не предусматривает попадания туда, где нужно использовать схему JavaScript (ссылки); </p><br /></li> <li><p>включает проверку AngularJS, VueJS; </p><br /></li> <li><p>расширенное покрытие случаев с записью атрибутов.</p><br /></li> </ul> <p>Обычные полиглот-пейлоады используют onload='alert ()', но у многих элементов нет такого события. В моем это: </p> <p>'»/test/></title/</script/</style/-->{{7×7}}<iframe/onload='alert``'</script><a href="//qwe.com">qwe</a><img src=x>${7*7}{{7*7}} <div style="padding-left: 20px;"> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-2514821055276660" crossorigin="anonymous"></script>  <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-2514821055276660" data-ad-slot="1200562049" data-ad-format="auto"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> </div>  <noindex> <div style="margin: 25px;" id="disqus_thread"></div> <script type="text/javascript"> var disqus_shortname = 'pcnewsru'; var disqus_identifier = '1106121'; var disqus_title = 'Эффективный поиск XSS-уязвимостей'; var disqus_url = 'http://pcnews.ru/blogs/effektivnyj_poisk_xss_uazvimostej-1106121.html'; (function() { var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js'; (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); })(); </script>   </noindex> </div> <br class="clearer"/> </div> <br class="clearer"/> <div id="footer-2nd"></div> <div id="footer"> <br/><br/> <ul class="horz-menu"> <li class="about"><a href="/info/about.html" title="О проекте">О проекте</a></li> <li class="additional-menu"><a href="/archive.html" title="Архив материалов">Архив</a> </li> <li class="additional-menu"><a href="/info/reklama.html" title="Реклама" class="menu-item"><strong>Реклама</strong></a> <a href="/info/partners.html" title="Партнёры" class="menu-item">Партнёры</a> <a href="/info/legal.html" title="Правовая информация" class="menu-item">Правовая информация</a> <a href="/info/contacts.html" title="Контакты" class="menu-item">Контакты</a> <a href="/feedback.html" title="Обратная связь" class="menu-item">Обратная связь</a></li> <li class="email"><a href="mailto:pcnews@pcnews.ru" title="Пишите нам на pcnews@pcnews.ru"><img src="/media/i/email.gif" alt="e-mail"/></a></li> <li style="visibility: hidden"> <noindex>  <script type="text/javascript"> var _tmr = window._tmr || (window._tmr = []); _tmr.push({id: "93125", type: "pageView", start: (new Date()).getTime()}); (function (d, w, id) { if (d.getElementById(id)) return; var ts = d.createElement("script"); ts.type = "text/javascript"; ts.async = true; ts.id = id; ts.src = (d.location.protocol == "https:" ? "https:" : "http:") + "//top-fwz1.mail.ru/js/code.js"; var f = function () { var s = d.getElementsByTagName("script")[0]; s.parentNode.insertBefore(ts, s); }; if (w.opera == "[object Opera]") { d.addEventListener("DOMContentLoaded", f, false); } else { f(); } })(document, window, "topmailru-code"); </script> <noscript> <div style="position:absolute;left:-10000px;"> <img src="//top-fwz1.mail.ru/counter?id=93125;js=na" style="border:0;" height="1" width="1" alt="Рейтинг@Mail.ru"/> </div> </noscript>  </noindex> </li> </ul> </div> <!--[if lte IE 7]> <iframe id="popup-iframe" frameborder="0" scrolling="no">