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

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

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

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

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

Как распознать атаку межсайтового скриптинга?

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

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

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

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

• Установите качественное антивирусное решение на свой компьютер
• Настройте автоматическое обновление всех сторонних программ
• Загрузите инструмент для сканирования веб-сайтов на предмет наличия в коде уязвимостей типа XSS

Защититесь от межсайтового скриптинга

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

XSS атаки: что это такое

АБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ

ABCDEFGHIJKLMNOPQRSTUVWXYZ0-9

Cross Site Sсriрting, или XSS (в переводе с английского — межсайтинговый скриптинг) — это тип уязвимости сайтов, возникающий при попадании пользовательских скриптов в генерируемые веб-сервером страницы.

По мнению специалистов из securitylab.ru, на XSS приходится более 15% интернет-атак. Они позволяют получить третьим лица доступ к пользовательским файлам cookies и другой конфиденциальной информации, затруднить взаимодействие посетителей с сайтом или внедрить в их операционную систему вредоносный код. Поэтому при раскрутке сайта разрабатывают методы защиты от данной угрозы.

Виды

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

В зависимости от каналов внедрения кода выделяются следующие уязвимости:

• использование HTML тегов в сообщениях на сайте для форматирования текста. При отсутствии должного уровня фильтрации таких постов в них могут быть вставлены теги <script>, отправляющие взломщику cookies пользователей при просмотре, например, определенной темы форума, или открывающие в браузере посетителей произвольные ссылки. Защитой от такой атаки служит удаление всех тегов, кроме разрешенных;
• отсутствие фильтрации разрешенных тегов: названий атрибутов и их значений. Вредоносный скрип может быть внедрен, к примеру, в тег img. Для защиты от данной уязвимости применяется жесткая фильтрация тегов и запрет использования протоколов data и javascript во всех гиперссылках;
• изменение кодировки в тайтле страницы. Для устранения такой уязвимости при поисковой оптимизации сайта кодировка страницы указывается до пользовательских полей.

Также различают моментальные XSS, при которых скрипт возвращается сразу как ответ на HTTP запрос, и отложенные — код сохраняется в системе и внедряется в HTML страницу через определенный период времени.

Индексация сайта

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

Другие термины на букву «X»

XenuXML выдача Яндекса

Все термины SEO-Википедии

Теги термина

Вредоносные технологии

Находи клиентов. Быстрее!

Работаем по будням с 9:30 до 18:30. Заявки, отправленные в выходные, обрабатываем в первый рабочий день до 10:30.

Приложи файл или ТЗ

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

Работаем по будням с 9:30 до 18:30. Заявки, отправленные в выходные, обрабатываем в первый рабочий день до 10:30.

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

наверх

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

Твиттер

WhatsApp

Фейсбук

Реддит

LinkedIn

Эл. адрес

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

Что хранится в межсайтовых сценариях?

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

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

POST/сообщение/комментарий HTTP/1.1
Хост: уязвимый-website.com
Длина содержимого: 100
postId=3&comment=Этот+сообщение+было+чрезвычайно+полезным.&name=Carlos+Montoya&email=carlos%40normal-user.net

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

Это сообщение было очень полезным.

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

В запросе злоумышленника этот комментарий будет закодирован в URL как:

комментарий=%3Cscript%3E%2F*%2BBad%2Bstuff%2Bhere...%2B*%2F%3C%2Fscript%3E

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

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

ЛАБОРАТОРИЯ

УЧЕНИК
Сохраненный XSS в HTML-контексте без кодирования

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

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

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

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

Подробнее

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

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

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

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

Подробнее

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

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

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

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

Точки входа в обработку заявки включают:

• Параметры или другие данные в строке запроса URL и тексте сообщения.
• Путь к файлу URL.
• Заголовки HTTP-запросов, которые могут быть неприменимы в отношении отраженного XSS.
• Любые внеполосные маршруты, по которым злоумышленник может доставить данные в приложение. Существующие маршруты полностью зависят от функциональности, реализуемой приложением: приложение веб-почты будет обрабатывать данные, полученные в электронных письмах; приложение, отображающее ленту Twitter, может обрабатывать данные, содержащиеся в сторонних твитах; а агрегатор новостей будет включать данные с других веб-сайтов.

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

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

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

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

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

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

Контексты межсайтового скриптинга | Академия веб-безопасности

Твиттер

WhatsApp

Фейсбук

Реддит

LinkedIn

Эл. адрес

При тестировании отраженного и сохраненного XSS ключевой задачей является определение контекста XSS:

• Место в ответе, где появляются данные, контролируемые злоумышленником.
• Любая проверка ввода или другая обработка, которая выполняется с этими данными приложением.

На основе этих сведений вы можете выбрать одну или несколько полезных нагрузок XSS-кандидатов и проверить их эффективность.

Примечание

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

XSS между тегами HTML

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

Некоторые полезные способы выполнения JavaScript:

ЛАБОРАТОРИЯ

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

ЛАБОРАТОРИЯ

УЧЕНИК
Сохраненный XSS в контексте HTML без кодирования

ЛАБОРАТОРИЯ

ПРАКТИК
XSS отражен в контексте HTML с блокировкой большинства тегов и атрибутов

ЛАБОРАТОРИЯ

ПРАКТИК
XSS отражен в HTML-контексте со всеми заблокированными тегами, кроме пользовательских

ЛАБОРАТОРИЯ

ЭКСПЕРТ
Отраженный XSS с обработчиками событий и href атрибуты заблокированы

ЛАБОРАТОРИЯ

ПРАКТИК
Отраженный XSS с некоторой разрешенной разметкой SVG

XSS в атрибутах HTML-тегов

Когда контекст XSS находится в значении атрибута HTML-тега, иногда вы можете завершить значение атрибута, закрыть тег и ввести новый. Например:

">

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

" автофокус onfocus = предупреждение (document.domain) x = "

Вышеуказанная полезная нагрузка создает событие onfocus , которое будет выполнять JavaScript, когда элемент получает фокус, а также добавляет атрибут autofocus , чтобы попытаться вызвать событие onfocus автоматически без какого-либо взаимодействия с пользователем. Наконец, он добавляет x=" , чтобы изящно исправить следующую разметку.

ЛАБОРАТОРИЯ

УЧЕНИК
Отраженный XSS в атрибут с угловыми скобками HTML-кодировка

Иногда контекст XSS относится к типу атрибута HTML-тега, который сам по себе может создавать контекст, доступный для сценариев. Здесь вы можете выполнить JavaScript без необходимости завершать значение атрибута. Например, если контекст XSS находится в атрибуте href тега привязки, вы можете использовать псевдопротокол javascript для выполнения скрипта. Например:

ЛАБОРАТОРИЯ

УЧЕНИК
Сохраненный XSS в атрибуте anchor href с двойными кавычками HTML-кодировка

Вы можете столкнуться с веб-сайтами, которые кодируют угловые скобки, но при этом позволяют вводить атрибуты. Иногда эти инъекции возможны даже внутри тегов, которые обычно не запускают события автоматически, например канонического тега. Вы можете использовать это поведение, используя ключи доступа и взаимодействие с пользователем в Chrome. Клавиши доступа позволяют вам предоставлять сочетания клавиш, которые ссылаются на определенный элемент. 9Атрибут 0013 accesskey позволяет определить букву, нажатие которой в сочетании с другими клавишами (они различаются на разных платформах) вызовут срабатывание событий. В следующей лабораторной работе вы можете поэкспериментировать с ключами доступа и использовать канонический тег.
Вы можете использовать XSS в скрытых полях ввода, используя метод, изобретенный PortSwigger Research.

ЛАБОРАТОРИЯ

ПРАКТИК
Отраженный XSS в теге канонической ссылки

XSS в JavaScript

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

Завершение существующего сценария

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

<скрипт>
...
var input = 'управляемые данные здесь';
...


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

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

ЛАБОРАТОРИЯ

ПРАКТИК
Отраженный XSS в строку JavaScript с одинарной кавычкой и обратной косой чертой

Выход из строки JavaScript

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

Некоторые полезные способы выхода из строкового литерала:

'-оповещение (документ.домен)-'
';alert(document.domain)//

ЛАБОРАТОРИЯ

УЧЕНИК
Отраженный XSS в строку JavaScript с угловыми скобками HTML-кодировка

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

Например, предположим, что ввод:

';предупреждение(документ.домен)//

преобразуется в:

\';alert(document.domain)//

Теперь вы можете использовать альтернативную полезную нагрузку:

\';alert(document.domain)//

который преобразуется в:

\\';alert(document. domain)//

Здесь первая обратная косая черта означает, что вторая обратная косая черта интерпретируется буквально, а не как специальный символ. Это означает, что теперь кавычка интерпретируется как признак конца строки, и поэтому атака завершается успешно.

ЛАБОРАТОРИЯ

ПРАКТИК
Отраженный XSS в строку JavaScript с угловыми скобками и двойными кавычками HTML-кодирование и экранирование одинарных кавычек

Некоторые веб-сайты усложняют XSS, ограничивая символы, которые вам разрешено использовать. Это может быть на уровне веб-сайта или путем развертывания WAF, который предотвращает попадание ваших запросов на веб-сайт. В этих ситуациях вам нужно поэкспериментировать с другими способами вызова функций, которые обходят эти меры безопасности. Один из способов сделать это — использовать выдать оператор с обработчиком исключений. Это позволяет передавать аргументы функции без использования круглых скобок. Следующий код назначает функцию alert() глобальному обработчику исключений, а оператор throw передает 1 обработчику исключений (в данном случае alert ). Конечным результатом является то, что функция alert() вызывается с 1 в качестве аргумента.

onerror=предупреждение;бросить 1

Существует несколько способов использования этой техники для вызова функций без круглых скобок.

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

ЛАБОРАТОРИЯ

ЭКСПЕРТ
Отражение XSS в URL-адресе JavaScript с блокировкой некоторых символов

Использование HTML-кодирования

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

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

Например, если контекст XSS выглядит следующим образом:

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

'-alert(document.domain)-'

'; Последовательность — это объект HTML, представляющий собой апостроф или одинарную кавычку. Поскольку браузер HTML-декодирует значение атрибута onclick до того, как будет интерпретирован JavaScript, объекты декодируются как кавычки, которые становятся разделителями строк, и поэтому атака завершается успешно.

ЛАБОРАТОРИЯ

ПРАКТИК
Сохраненный XSS в событие onclick с угловыми скобками и двойными кавычками HTML-кодирование, одинарные кавычки и обратная косая черта

XSS в литералах шаблона JavaScript

Литералы шаблонов JavaScript — это строковые литералы, допускающие встраивание выражений JavaScript. Встроенные выражения оцениваются и обычно объединяются с окружающим текстом. Литералы шаблонов заключаются в обратные кавычки вместо обычных кавычек, а встроенные выражения идентифицируются с помощью 9 символов.0013 ${…} синтаксис.

Например, следующий сценарий напечатает приветственное сообщение, включающее отображаемое имя пользователя:

document.getElementById('message').innerText = `Добро пожаловать, ${user.displayName}.`;

Когда контекст XSS находится в литерале шаблона JavaScript, нет необходимости завершать литерал.

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