Тестирование на межсайтовый скриптинг (XSS)

Узнайте, как протестировать межсайтовый скриптинг (XSS), из этой статьи Джозефа Маршалла, разработчика веб-приложений и внештатного автора, авторами которого являются The Atlantic, Kirkus Review и киноблог SXSW. Ему также нравится подрабатывать внештатным исследователем безопасности, работая со сторонними рынками уязвимостей, такими как Bugcrowd и HackerOne.

Межсайтовый скриптинг (XSS) — это уязвимость, вызванная исключениями, встроенными в политику одного и того же происхождения браузера, которая ограничивает загрузку ресурсов (изображений, таблиц стилей и JavaScript) из внешних источников.

XSS, постоянно появляющийся в опросе OWASP Top-10 уязвимостей веб-приложений, потенциально может быть очень опасным, постоянным эксплойтом, который затрагивает большую часть пользовательской базы целевого сайта. Его также может быть трудно искоренить, особенно на сайтах, которые имеют большие поверхности атаки, с большим количеством входных данных, входов в систему, дискуссионных потоков и т. д., которые необходимо защитить.

В этой статье будут рассмотрены различные разновидности XSS (постоянные, отраженные, основанные на DOM и т. д.), а также способы их тестирования. Вы можете найти полный код для этой статьи на

Технические требования

Вам нужно будет настроить и использовать инструменты из командной строки терминала macOS. Вам также потребуется использовать Burp Suite, расширение Burp XSS Validator и информацию из репозитория SecLists GitHub (для обеспечения отправки вредоносных фрагментов XSS. Когда вы используете браузер обычно или в сочетании с Burp, вы продолжите использовать Chrome (66.0.3359.139).Использование расширения XSS Validator потребует от вас установки Phantomjs, безголового браузера с поддержкой сценариев.

Краткий обзор XSS — множество разновидностей XSS

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

Когда браузер загружает атрибут src в тег HTML, он выполняет код, на который указывает этот атрибут. Это не обязательно должен быть файл — это может быть просто код, включенный в строку атрибута. И не только атрибут src может выполнять JavaScript.

Ниже приведен пример фрагмента кода для тестирования XSS. Он использует атрибут onmouseover для выполнения JavaScript alert() как классическая канарейка XSS:

<a onmouseover="alert(document.location)"href="#">snippet text</a>

document.location включен как способ простой ссылки на точный URL-адрес, где происходит XSS.

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

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

Существует также XSS на основе DOM, более специализированный тип атаки, который основан на предоставлении пользователю сгенерированной хакером ссылки, содержащей полезную нагрузку XSS, которая предложит браузеру пользователя открыть ссылку, возвращая полезную нагрузку по мере ее создания. DOM и выполняет код.

Хотя хранимая/постоянная XSS, отраженная XSS и XSS на основе DOM — все это возможные группы разновидностей XSS, другой способ думать о различных типах XSS — разделить ошибку на клиентскую XSS и серверную XSS. В этой структуре существуют как хранимые, так и отраженные типы как для клиентских, так и для серверных вариантов: Server XSS возникает, когда непроверенные пользовательские данные предоставляются сервером либо через запрос (отраженный XSS), либо в сохраненных местоположениях (сохраненный XSS), в то время как клиент XSS — это просто выполнение непроверенного кода в клиенте из тех же мест.

Тестирование на XSS — где его найти и как проверить

Есть несколько отличных методов обнаружения XSS. Начните с Burp и расширения Burp, связанного с XSS.

Burp Suite и XSS-валидатор

Одной из проблем с автоматическими и полуавтоматическими решениями для XSS является отличие сигнала от шума. Для этого полезный подключаемый модуль Burp, XSS Validator, запускает веб-сервер на базе PhantomJS для получения результатов запросов Burp и ищет строку, введенную в вызов alert(), встроенный в примененные фрагменты XSS. Он обеспечивает чистый способ отбраковки результатов ваших XSS-запросов на абсолютно подтвержденные уязвимости.

Самый простой способ загрузить расширение XSS Validator Burp — через магазин Bapp. Просто перейдите в магазин на вкладке «Расширения» в Burp Suite и выберите расширение на торговой площадке (само собой разумеется, оно бесплатное). Вы также можете установить расширение вручную, следуя инструкциям в документации XSS Validator GitHub.

Помимо установки расширения, во время фактического тестирования вам потребуется запустить сервер, анализирующий входящие запросы Burp. Если вы клонируете репозиторий XSS Validator git, вы можете перейти в каталог xss-validator и запустить скрипт xss.js. Затем вы можете загрузить сервер и настроить его для работы в качестве отдельного фонового процесса одной простой строкой:

phantomjs xss.js &

С запущенным сервером XSS Validator и Burp Suite (boostrap_burp) перейдите к конкретному вводу формы, который вы хотите проверить на XSS. Чтобы продемонстрировать инструмент на испытанной полигоне, вы можете протестировать ввод формы на тестовом сайте веб-сканера (webscantest.com), который был спроектирован так, чтобы быть восприимчивым к XSS:

После прибытия на страницу — с отключенной функцией перехвата прокси-сервера Burp, чтобы вам не приходилось вручную перенаправлять весь трафик на пути туда — вы вводите что-то узнаваемое в поля формы, которые вы тестируете:

Теперь вернитесь к графическому интерфейсу Burp Suite и снова включите Intercept перед отправкой:

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

Вы хотите отправить этот запрос функции злоумышленника Burp, где вы можете сделать больше для управления данными POST. Для этого щелкните запрос правой кнопкой мыши и нажмите «Отправить злоумышленнику»:

Когда вы окажетесь в окне Intruder, перейдите на вкладку «Позиции», где вы можете увидеть параметры запроса POST и идентификаторы файлов cookie, уже выбранные в качестве позиций полезной нагрузки. Идите вперед и оставьте эти значения по умолчанию и перейдите на вкладку Payloads, чтобы выбрать, чем вы будете заполнять эти входы. Чтобы интегрироваться с расширением XSS Validator, вам необходимо внести изменения в эти первые три параметра, связанные с полезной нагрузкой, следующим образом:

Вам нужно сделать еще одно изменение настроек, прежде чем вы сможете начать атаку. Если вы перейдете на вкладку xssValidator, вы увидите случайную строку, сгенерированную в поле Grep Phrase, и вы также можете заметить маркер, объясняющий, что успешные атаки будут обозначаться наличием Grep Phrase:

Добавьте эту фразу grep в раздел Grep — Match на вкладке «Параметры», чтобы при просмотре результатов атаки вы могли видеть флажок, указывающий, появилась ли ваша фраза в ответе на атаку:

Как только эта фраза будет добавлена, вы готовы начать атаку. Нажмите кнопку «Начать атаку» в правом верхнем углу окна «Параметры» (и любого другого).

После нажатия кнопки вы должны увидеть всплывающее окно атаки и начать самозаполнение результатами отправки фрагмента XSS:
10.ПНГ

И вуаля! Вы можете увидеть наличие вашей фразы grep, которая означает, что ваши отправки были успешными, для нескольких комбинаций тегов/атрибутов, сгенерированных отправками XSS Validator.

Если вы нашли эту статью интересной, вы можете изучить Практическая охота за ошибками для пентестеров подробное пошаговое руководство по обнаружению, тестированию и документированию распространенных уязвимостей веб-приложений. Практическая охота за ошибками для пентестеров показывает, как технические специалисты, заинтересованные в безопасности, могут начать продуктивно и выгодно участвовать в программах вознаграждения за обнаружение ошибок. Вы можете получить все книги Packt всего за 5 долларов до 21 января 2019 года. Так чего же вы ждете? Воспользуйтесь предложением сегодня и станьте выдающимся ИТ-специалистом!