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

1 февраля 2024 г.

Согласно статистике, которую я видел, и моему опыту, 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, поймите потенциальное влияние и расставьте приоритеты в устранении проблем.

Шаги:

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

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

```Javascript

(%0ejavascript:alert(/XSS/))

// Отображение диалогового окна оповещения с сообщением «XSS».

// Загружаем сломанное изображение, вызываем оповещение с номером «123».

// Полезная нагрузка для кражи файлов cookie: // Отправляет файлы cookie жертвы на сервер, контролируемый злоумышленником.

// Полезная нагрузка XSS на основе DOM: #"> // Использует манипуляции с DOM, вызывает оповещения на уязвимых страницах. <код>`` 2. Отправьте входные данные и посмотрите, выполнится ли сценарий. 3. Если да, то приложение уязвимо для XSS-атак. 4. Если сценарий не выполняется, попробуйте изменить входные данные, добавив другие теги HTML, напримерили`<strong>,</strong> и посмотрите, отражаются ли они на странице, ==например== (у меня это почти всегда работает):

<b>t</b>#`"/*—est 5. Вы можете добавить скрипт для запроса параметров URL-адреса вашего веб-приложения или имени пользователя, имен загруженных файлов или любого текста, который будет отображаться на странице приложения, которую вы можете изменить. 6. Помните о предварительной проверке входных данных. Всегда старайтесь отправлять значение с помощью прямого запроса (с помощью Postman, Burp или любых подобных инструментов). 7. Проверьте консоль браузера в инструментах разработчика, потому что иногда вы можете не увидеть видимых изменений на странице, но некоторые символы, например `"/*— может нарушить JS/HTML страницы, и вы увидите предупреждение в консоли, которое может быть подсказкой о том, как изменить полезную нагрузку, чтобы получить XSS PoC

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

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

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

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

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

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

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

PoC XSS

Демонстрирует подтверждение уязвимости 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 и обеспечить адекватную безопасность веб-приложений.

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

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

https://owasp.org/www-community/attacks/xss/

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

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

:::

Оригинал