XSS — уязвимость и как ее не упустить

Время прочтения: 5 мин.

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

Cross-Site Scripting– часто встречаемая уязвимость в веб-приложениях. С помощью данной лазейки злоумышленник может внедрить JavaScript-код, не предусмотренный разработчиком, который будет выполняться при входе пользователя на страницу.

Наличие данной уязвимости может привести к:

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

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

Как же все-таки искать, определять и бороться с данной проблемой?

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

В качестве простых и распространенных проверок на наличие данной уязвимости можно использовать код, который после успешной отработки откроет пользователю стандартное браузерное окно — например alert. Также нужно обращать внимание на get- параметры запроса, передающиеся в URL запросе, если в get- параметре, при поиске появился запрос (из поискового запроса), то велика вероятность, что страница подвержена уязвимости. В этом случае тот же код (“<script>alert(1)</script>”) вместо запроса подставляем  get параметр и обновляем страницу. В случае успеха в браузере появится подобное окно:

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

ХSStrike – инструмент для поиска XSS уязвимостей. Данный сканер прост в первоначальной настройке и имеет открытый код. Вместо того, чтобы вводить полезную нагрузку и проверять ее работу, как это делают все другие инструменты, XSStrike анализирует ответ с помощью нескольких анализаторов, а затем создает полезные нагрузки, которые гарантированно работают с помощью анализа контекста, интегрированного с механизмом фаззинга^[1]. Вот несколько примеров полезных нагрузок, генерируемых XSStrike:

Основные особенности:

• Отраженное и DOM XSS сканирование
• Многопоточное сканирование
• Анализ контекста
• Настраиваемое ядро
• Обнаружение и уклонение от WAF
• Сканирование устаревших JS-библиотек
• Интеллектуальный генератор полезной нагрузки
• Ручной анализатор HTML и JavaScript
• Мощный движок фаззинга
• Слепая поддержка XSS
• Тщательно проработанный рабочий процесс
• Полная поддержка HTTP
• Полезные данные грубой силы из файла
• При поддержке Photon , Zetanize и Arjun

Пример простого запуска, на месте кавычек указываем url, которую хотим протестировать:

python xsstrike. py -u " " --blind

В ходе проверки, утилита обнаруживает уязвимый параметр page (Reflections found). Злоумышленник получает возможность передать js код (пример кода указан в строке Payload), который будет исполнен на странице. Такой тип XSS уязвимостей называется reflected XSS.

Функционал утилиты позволяет запустить проверку по всему сайту, для запуска требуется лишь указать стартовую страницу. Дальше сканер выполняет исследование всех найденных страниц.

python xsstrike.py -u " " --blind --crawl -l 100

“-l 100” отвечает за количество страниц обхода.

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

С помощью данного сканера возможно передавать HTTP заголовки, осуществлять проверку форм и много другого, полный перечень возможностей указан в описании инструмента.

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

Найти данный инструмент с полным описание можно по ссылке.

^[1] Методика тестирования программного обеспечения, суть которой заключается в автоматизированном обнаружении ошибок реализации путем отправки заведомо неверных данных и анализе реакции программы на них.

Уязвимости на странице | Введение в тестирование веб-приложений

Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

Видео может быть заблокировано из-за расширений браузера. В статье вы найдете решение этой проблемы.

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

Любые проекты, чаты и сайты пишут люди. Чем крупнее проект, тем больше шансов, что у сайта или приложения найдутся так называемые «дыры» — незащищенные участки, которыми могут воспользоваться злоумышленники.

В этом уроке мы познакомимся с понятием уязвимости и разберем одну из самых простых в исполнении атак — XSS

Уязвимости и атаки

Цели злоумышленников при атаках на сайты или приложения обычно следующие:

• Кража персональных данных пользователей

• Кража аккаунтов

• Кража банковских данных

• Передача вирусов на компьютеры пользователей

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

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

Существует два самых распространенных типа атак:

В дополнительных материалах к этому уроку будет приложена ссылка на список ТОП-10 атак в интернете по версии OWASP — некоммерческой организации, которая исследует информационную безопасность и виды атак на ресурсы.

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

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

XSS

Когда злоумышленник отправил вместо обычного сообщения разметку на HTML, он использовал атаку Cross-Site Scripting или XSS. Сокращение начинается с буквы «X», чтобы не было путаницы с языком стилей CSS. При XSS должен выполниться любой сторонний код, который был передан на сайт. Это может быть:

• HTML-разметка

• JavaScript код

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

Для примера создадим такой сайт и отправим код в незащищенное поле. Код — обычный JavaScript код, в котором выводится сообщение для пользователя в отдельном окне:

<script>alert('Я отправил вам скрипт! Пришлите денег, пожалуйста :(')</script>

Так выглядит страница до ввода сообщения со скриптом:

При вводе сообщения со скриптом браузеры всех пользователей автоматически выполнят скрипт, так как в чате нет защиты от XSS:

Это происходит, потому что браузер обрабатывает все символы в сообщении, в том числе и служебные, такие как <, >. Чтобы безопасно вывести сообщение и не выполнить код, используется замена символов на мнемоники.

Мнемоники — специальные символы, которые браузер не обрабатывает как код. Такой процесс называется экранированием символов и повсеместно используется в программировании.

В примере выше, чтобы защититься от выполнения кода, стоит заменить все символы < на мнемонику <, а символы > на >. Браузеры не умеют обрабатывать такой текст как код, но для пользователя все символы вернутся в исходное состояние.

<script>alert('Я отправил вам скрипт! Пришлите денег, пожалуйста :(')</script>

Для тестирования XSS используются два способа:

1. Если переданная строка в форме где-то отображается после отправки, то возможно отправить любой HTML-тег с текстом. Например, <h2>Hello</h2>

2. Вместо HTML воспользуйтесь кодом на JavaScript, как в примере выше. Действие функции alert() будет заметно сразу

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

Если ни один из способов не сработал, значит, простыми способами атаку не использовать. Это не означает, что уязвимостей нет, но так отсекаются самые распространенные способы, которыми любят пользоваться начинающие хакеры.

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

При использовании XSS атака происходит на пользователей, а не на сам сайт и его внутреннюю структуру. В противовес такому подходу используют атаку под названием SQL Injection. Она направлена на базу данных сайта.

Выводы

В этом уроке мы базово рассмотрели тему информационной безопасности и простых атак на веб-приложения. Так как тема безопасности большая для одного урока, то мы остановились на одной из простых в исполнении атаки — Cross-site Script.

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

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

С опытом вы сможете тестировать большое количество разных атак и дополнительно защищать приложение от злоумышленников.

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Электронная почта *

Отправляя форму, вы принимаете «Соглашение об обработке персональных данных» и условия «Оферты», а также соглашаетесь с «Условиями использования»

Наши выпускники работают в компаниях:

Что отражает XSS (межсайтовый скриптинг)? Учебник и примеры

Твиттер

WhatsApp

Фейсбук

Реддит

LinkedIn

Электронная почта

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

Что отражает межсайтовый скриптинг?

Отраженный межсайтовый скриптинг (или XSS) возникает, когда приложение получает данные в HTTP-запросе и включает эти данные в немедленный ответ небезопасным способом.

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

https://insecure-website.com/search?term=gift

Приложение повторяет указанный поисковый запрос в ответе на этот URL:

Вы искали: подарок

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

https://insecure-website.com/search?term=

Этот URL приводит к следующему ответу:

Вы искали:

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

ЛАБОРАТОРИЯ

УЧЕНИК
Отражение XSS в HTML-контекст без кодирования

Влияние отраженных XSS-атак

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

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

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

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

Подробнее

Использование уязвимостей межсайтового скриптинга

Отражение XSS в различных контекстах

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

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

Подробнее

Контексты межсайтового скриптинга

Как найти и протестировать отраженные XSS-уязвимости

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

Проверка отраженных XSS-уязвимостей вручную включает следующие шаги:

• Проверка каждой точки входа. Протестируйте отдельно каждую точку входа для данных в HTTP-запросах приложения. Сюда входят параметры или другие данные в строке запроса URL-адреса и тексте сообщения, а также путь к файлу URL-адреса. Он также включает заголовки HTTP, хотя XSS-подобное поведение, которое может быть вызвано только определенными заголовками HTTP, на практике может быть непригодным для использования.
• Отправка случайных буквенно-цифровых значений. Для каждой точки входа отправьте уникальное случайное значение и определите, отражено ли это значение в ответе. Значение должно быть спроектировано таким образом, чтобы выдержать большую часть проверки ввода, поэтому оно должно быть достаточно коротким и содержать только буквенно-цифровые символы. Но он должен быть достаточно длинным, чтобы случайные совпадения в ответе были маловероятными. Обычно идеально подходит случайное буквенно-цифровое значение длиной около 8 символов. Вы можете использовать числовые данные Burp Intruder [https://portswigger. net/burp/documentation/desktop/tools/intruder/payloads/types#numbers] со случайно сгенерированными шестнадцатеричными значениями для генерации подходящих случайных значений. И вы можете использовать настройки полезной нагрузки grep Burp Intruder, чтобы автоматически помечать ответы, содержащие отправленное значение.
• Определить контекст отражения. Для каждого места в ответе, где отображается случайное значение, определите его контекст. Это может быть текст между тегами HTML, внутри атрибута тега, который может быть заключен в кавычки, внутри строки JavaScript и т. д.
• Проверка полезной нагрузки-кандидата. В зависимости от контекста отражения протестируйте первоначальную полезную нагрузку XSS-кандидата, которая вызовет выполнение JavaScript, если она будет отражена в ответе без изменений. Самый простой способ протестировать полезные нагрузки — отправить запрос в Burp Repeater, изменить запрос, чтобы вставить полезную нагрузку-кандидата, отправить запрос, а затем просмотреть ответ, чтобы увидеть, сработала ли полезная нагрузка. Эффективный способ работы — оставить исходное случайное значение в запросе и поместить потенциальную полезную нагрузку XSS до или после него. Затем установите случайное значение в качестве условия поиска в представлении ответов Burp Repeater. Burp выделит каждое место, где появляется поисковый запрос, что позволит вам быстро найти отражение.
• Проверка альтернативных полезных нагрузок. Если полезная нагрузка-кандидат XSS была изменена приложением или полностью заблокирована, вам потребуется протестировать альтернативные полезные нагрузки и методы, которые могут обеспечить работающую XSS-атаку, в зависимости от контекста отражения и типа выполняемой проверки ввода. . Дополнительные сведения см. в разделе контексты межсайтовых сценариев

.

• Протестируйте атаку в браузере. Наконец, если вам удастся найти полезную нагрузку, которая работает в Burp Repeater, перенесите атаку на реальный браузер (вставив URL-адрес в адресную строку или изменив запрос в представлении перехвата Burp Proxy, и посмотрите, внедренный JavaScript действительно выполняется. Часто лучше всего выполнить какой-нибудь простой JavaScript, например alert(document.domain) , который вызовет видимое всплывающее окно в браузере, если атака будет успешной.

Общие вопросы об отраженном межсайтовом сценарии

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

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

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

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

Межсайтовый скриптинг можно разделить на три основные категории — Сохраненный XSS , Отраженный XSS и XSS на основе DOM .

Stored XSS (Persistent XSS)

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

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

Отраженный XSS (непостоянный XSS)

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

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

XSS на основе DOM

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

XSS-атака на основе DOM часто является атакой на стороне клиента, и вредоносная полезная нагрузка никогда не отправляется на сервер. Это еще больше затрудняет обнаружение для брандмауэров веб-приложений (WAF) и инженеров по безопасности, которые анализируют журналы сервера, потому что они никогда не увидят атаку. Объекты DOM, которыми чаще всего манипулируют, включают URL-адрес ( document.URL ), якорную часть URL-адреса ( location.hash ) и Referrer ( document.referrer ).

Обнаружение и предотвращение XSS

Межсайтовый скриптинг — очень старый метод, но уязвимости XSS остаются одними из самых распространенных в Интернете. Они по-прежнему упоминаются Open Web Application Security Project (OWASP) как одна из 10 главных угроз безопасности.

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

Вы можете узнать, как предотвратить атаки XSS, в следующей статье: Предотвращение атак XSS.

Часто задаваемые вопросы

Что хранится XSS (постоянный XSS)?

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

Узнайте больше о сохраненных (постоянных) XSS.

Что отражает XSS (непостоянный XSS)?

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

Подробнее о межсайтовых сценариях в целом.

Что такое XSS на основе DOM?

Межсайтовый скриптинг (XSS) на основе DOM происходит, когда веб-приложение записывает пользовательский ввод в объектную модель документа (DOM), затем считывает данные из DOM и выполняет их в браузере. Часто бывает так, что вредоносный код не отправляется на сервер, что затрудняет его обнаружение брандмауэрами веб-приложений (WAF) и инженерами по безопасности, которые анализируют журналы сервера.

Узнайте больше о межсайтовых сценариях на основе DOM.

Как обнаружить различные типы XSS?

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

This entry was posted in Популярное