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

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

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

Общая классификация XSS

Четкой классификации для межсайтового скриптинга не существует, но экспертами по всему миру выделено три основных типа.

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

Отраженные XSS (непостоянные). В этом случае вредоносная строчка выступает в роли запроса жертвы к зараженному веб-сайту. Работает этот принцип по следующей схеме:

DOM-модели. В этом варианте возможно использование как хранимых XSS, так и отраженных. Суть заключается в следующем:

Виды XSS по способу взаимодействия

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

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

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

Как проверить сайт на наличие уязвимостей XSS и защитить его

Для быстрой проверки сайта на наличие уязвимостей XSS можно воспользоваться специализированными сервисами, которые в автоматическом режиме проведут сканирование страницы. В обязательном порядке нужно проверять все URL, где возможна отправка данных со стороны пользователя (формы комментариев, обратная связь, поиск). В качестве примера можете использовать http://xss-scanner.com, но не стоит ограничиваться лишь одним инструментом.

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

Несколько советов по предотвращению использования XSS на вашем сайте:

Источник

XSS глазами злоумышленника

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

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

Как-то не очень страшно 🙂 Чем же действительно может быть опасной данная уязвимость?

Пассивная и активная

Существует два типа XSS уязвимостей — пассивная и активная.

Активная уязвимость более опасна, поскольку злоумышленнику нет необходимости заманивать жертву по специальной ссылке, ему достаточно внедрить код в базу или какой-нибудь файл на сервере. Таким образом, все посетители сайта автоматически становятся жертвами. Он может быть интегрирован, например, с помощью внедрения SQL-кода (SQL Injection). Поэтому, не стоит доверять данным, хранящимся в БД, даже если при вставке они были обработаны.

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

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

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

Кража Cookies

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

Источник

XSS: атака и защита с точки зрения C# программирования

XSS, или межсайтовый скриптинг, является одной из самых часто встречающихся уязвимостей в веб-приложениях. Она уже долгое время входит в OWASP Top 10 – список самых критичных угроз безопасности веб-приложений. Давайте вместе разберемся, как в вашем браузере может выполниться скрипт, полученный со стороннего сайта, и к чему это может привести (спойлер: например, к краже cookie). Заодно поговорим о том, что необходимо предпринять, чтобы обезопаситься от XSS.

Что такое XSS?

Межсайтовый скриптинг (XSS) — тип атаки на веб-системы: он заключается во внедрении в веб-страницу вредоносного кода, который взаимодействует с веб-сервером злоумышленника. Чаще всего вредоносный код выполняется в браузере пользователя при рендеринге страницы. Реже — от пользователя требуется выполнение дополнительных действий. Получается, что во многих случаях для использования XSS уязвимости злоумышленником пользователю необходимо просто открыть веб-страницу с внедрённым вредоносным кодом. Это одна из причин того, почему на момент написания статьи XSS занимает 7-ое место в OWASP Top 10 — списке самых опасных уязвимостей веб-приложений, сформированном в 2017 году.

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

Теперь проверим, что всё работает. Открываем страницу с пустым значением у параметра xss:

Открываем страницу со значением Not empty ‘xss’ parameter у параметра xss:

Отображение строки работает. А теперь самое интересное! Передадим в параметре xss строку .

В результате при открытии страницы код из параметра будет выполнен, и мы увидим диалоговое окно с текстом, переданным в метод alert:

Вау! JavaScript код, который мы передали через параметр xss, выполнился при отображении страницы. Таким образом я наполовину выполнил первый пункт из определения XSS атаки: на страницу внедрён код, который выполнился при отображении страницы, однако он не нанёс никакого вреда.

Теперь добавим взаимодействие внедрённого кода с веб-сервером злоумышленника. Аналогом веб-сервера в моём примере будет веб-сервис, написанный на C#. Код конечной точки веб-сервиса:

Чтобы обратиться к этому веб-сервису, я передам в параметре xss строку:

При открытии страницы код из параметра будет выполнен, и веб-сервису по адресу https://localhost:44394/AttackerEndPoint будет отправлен GET запрос, где в параметре stolenToken будет передана строка TEST_TOKEN. При получении запроса веб-сервис сохранит значение из параметра stolenToken в файл StolenTokenResult.txt.

Протестируем это поведение. Откроем страницу и увидим, что на ней ничего не отображается, кроме стандартного сообщения Value of the ‘xss’ parameter:.

Однако во вкладке ‘Network’ в инструментах разработчика висит сообщение о том, что веб-сервису по адресу https://localhost:44394/AttackerEndPoint был отправлен запрос:

Теперь проверим, что же содержится в файле StolenTokenResult.txt:

Ок, все работает. Таким образом мы почти выполнили все условия XSS атаки:

на страницу внедряется код через параметр xss в GET запросе;

этот код выполняется при открытии страницы и взаимодействует с веб-сервисом по адресу https://localhost:44394/AttackerEndPoint.

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

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

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

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

Осталось передать в GET запросе через параметр xss код, который получит из локального хранилища данные и отправит их на веб-сервис. Для этого я передам в параметре строку:

Вместо символа ‘+’ я использовал его кодированный вариант %2b, потому что в URL для символа ‘+’ отведено специальное назначение.

Проверяем, что все работает так, как я описал. Открываем страницу:

Здесь, как и в прошлый раз, только сообщение Value of the ‘xss’ parameter: посередине страницы. Осталось проверить, что код был выполнен и веб-сервису был отправлен запрос, где значение параметра stolenToken было равно USER_VERY_SECRET_TOKEN:

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

Теперь убедимся, что веб-сервис получил украденный токен:

Да, получил. В переменной stolenToken находится значение USER_VERY_SECRET_DATA. Ну и, естественно, веб-сервис сохранил его в файл StolenTokenResult.txt. Поздравляю, XSS атака прошла успешно.

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

Разобрав на примере, как может произойти XSS атака, стоит немного углубиться в теорию и познакомиться с типами XSS атак:

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

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

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

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

Способы защиты от XSS уязвимостей при разработке

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

В этом файле на странице отображается результат C# выражения Model.RequestId. Чтобы данный тип файла скомпилировался, C# выражение или блок C# кода должен начинаться с символа ‘@’. Однако этот символ не только позволяет использовать C# вместе с HTML разметкой в одном файле, но и указывает ASP.NET, что если блок кода или выражение возвращают значение, то перед его отображением на странице необходимо в значении кодировать символы HTML в HTML-сущности. HTML-сущности — это части текста («строки»), которые начинаются с символа амперсанда (&) и заканчиваются точкой с запятой (;). Сущности чаще всего используются для представления специальных символов (которые могут быть восприняты как часть HTML-кода) или невидимых символов (таких как неразрывный пробел). Таким образом ASP.NET защищает разработчиков от XSS атак.

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

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

Давайте я продемонстрирую данный способ защиты на примере XSS атаки, проведённой ранее. Вот только одна проблема: в JavaScript я не нашёл функции, которая кодирует HTML символы в HTML-сущности. Зато я нашёл в интернете способ, как быстро и легко написать такую функцию:

При написании этой функции была использована особенность свойства Element.innerHTML. Используем эту функцию на HTML странице из примера XSS атаки:

Здесь мы кодируем значение xss параметра при помощи функции htmlEncode перед отображением на странице.

Теперь откроем эту страницу, передав в параметре xss строку :

Как видите, при кодировании строки со скриптом браузер просто отображает эту строку на странице, а не выполняет скрипт.

Третий вариант защиты – это валидация данных, полученных от пользователя или какого-то другого внешнего источника (HTML запрос, база данных, файл и т.п.). Для этого типа защиты хорошо подходят регулярные выражения. Их можно использовать для отлова данных, содержащих опасные символы или конструкции. При обнаружении подобных данных валидатором приложение просто должно выдать пользователю сообщение об опасных данных и не отправлять их далее на обработку.

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

Автоматизированный поиск XSS уязвимостей

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

И все-таки более логичным и дешёвым вариантом является поиск и исправление уязвимостей на ранних стадиях разработки. Значительную помощь в этом оказывают XSS сканеры и статические анализаторы кода. Например, в контексте разработки на языке C# одним из таких статических анализаторов является PVS-Studio. В этом анализаторе недавно появилась новая C# диагностика — V5610, которая как раз ищет потенциальные XSS уязвимости. Также можно использовать оба типа инструментов, потому что каждый из них имеет собственную зону ответственности. Благодаря этому вы обнаружите как существующие уязвимости в проекте, так и уязвимости, которые будут возникать при развитии проекта.

Если вам интересна тема уязвимостей в целом, а также способы их обнаружения с помощью статического анализа, то предлагаю прочитать статью «OWASP, уязвимости и taint анализ в PVS-Studio C#. Смешать, но не взбалтывать».

Заключение

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

P.S. Если хотите получить немного практики с XSS (в учебных целях), предлагаю попробовать игру про XSS от Google.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Valery Komarov. XSS: attack, defense — and C# programming.

Источник

Что такое атака с использованием межсайтового скриптинга? Определение и описание

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

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

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

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

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

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

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

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

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

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

Воздействие межсайтового скриптинга

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

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

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

Атаки с использованием межсайтового скриптинга можно разделить на три основные категории: хранимые, отраженные и на основе DOM.

Хранимые (постоянные)

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

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

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

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

Межсайтовый скриптинг на основе DOM

Межсайтовый скриптинг на основе DOM использует уязвимость DOM-модели (Document Object Model – объектной модели документа), а не HTML. В отраженных и хранимых атаках с использованием межсайтового скриптинга данные, полученные в результате эксплуатации уязвимости, отображаются на странице ответа. Однако при межсайтовом скриптинге на основе DOM исходный HTML-код атаки и ответ будут совпадать, то есть данные не могут быть получены в ответе на запрос, их можно получить только в среде выполнения или при исследовании DOM-модели страниц.

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

Примеры атак с использованием межсайтового скриптинга

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

Теперь при каждом доступе к странице помещенный в комментарий HTML-тег активирует файл JavaScript, размещенный на другом сайте, и позволяет украсть файлы cookie сеансов посетителей страницы.

Файлы cookie сеансов позволяют злоумышленникам взламывать учетные записи посетителей и получать доступ к их личной информации и финансовым данным. Между тем, посетители страницы, возможно, даже не прокрутили до раздела комментариев, и не подозревают о том, что произошла атака.

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

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

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

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

Чтобы не стать жертвой атаки с использованием межсайтового скриптинга, пользователи должны:

Источник