Как предотвратить межсайтовый скриптинг XSS на основе DOM |

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

Мануал

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

Этот мощный скриптовый язык привнес интерактивность и анимацию в сеть.

Но с большой силой приходит большая ответственность.

Межсайтовый скриптинг (XSS) остается неизменной опорой в топ-10 OWASP.

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

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

Объектная модель документа (DOM) позволяет веб-разработчикам диктовать через исходный код HTML, как веб-браузер пользователя должен отображать веб-страницу.

XSS-атаки на основе DOM направлены на использование DOM в два простых этапа:

  • Создание источника. Внедрить вредоносный скрипт в свойство, которое считается подверженным атакам XSS на основе DOM. Общие векторы внедрения включают объекты document.url, document.location и document.referrer.
  • Использование приемника: приемник – это точка в потоке данных, в которой браузер выполняет вредоносный код JavaScript, скрытый в DOM. Общие приемники включают document.write, setTimeout и setInterval.

В качестве типичного примера того, как выполняется атака XSS на основе DOM, предлагается прочитать DOM XSS: объяснение межсайтового скриптинга на основе DOM.

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

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

  • Объектная модель документа (DOM) – действует как стандартный способ представления объектов HTML (т. е. <div> </ div>) в иерархической форме.
  • Межсайтовый скриптинг (XSS) – специфическая уязвимость веб-приложения.

При этом DOM XSS использует DOM для использования XSS, полагаясь на небезопасную обработку пользовательского ввода на статической или динамической HTML-странице.

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

document.baseURI

Чтобы построить какую-то часть страницы, без санации возвращаемого значения.

Тем не менее, цель этой статьи не в том, чтобы полностью объяснить DOM XSS, а в том, как защититься от него.

Пример

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

http://testhtml5.vulnweb.com/#/redir?url=javascript:alert("DOM XSS on: " + document.domain)

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

Полезная нагрузка встроена в URI и поэтому может быть легко включена в фишинговую кампанию.

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

Простой, но эффективный способ сбора паролей.

Если мы будем копать глубже, мы обнаружим, что маршрут #redir выполняется другим файлом, который называется redir.html.

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

<script>
    var redirUrl = decodeURIComponent(window.location.hash.slice(window.location.hash.indexOf("?url=")+5));
    if (redirUrl) window.location = redirUrl;
</script>

По сути, мы используем источник window.location.hash, который оценивается в приемнике элемента HTML.

Санация

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

Эти полезные нагрузки никогда не отправляются на сервер из-за того, что они находятся за фрагментом HTML (все за символом #).

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

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

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

Избегайте таких методов, как:

document.innerHTML

И вместо этого используйте более безопасные функции при использовании пользовательского ввода, например, так:

document.innerText
document.textContent

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

Кроме того, избегайте использования пользовательского ввода.

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

Помните, что DOM XSS и XSS не являются взаимоисключающими

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

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

Для того, чтобы получить отличную шпаргалку о том, как полностью предотвратить DOM XSS, я очень рекомендую ознакомиться с Шпаргалкой по профилактике XSS на основе OWASP DOM.

Заключение

Наконец, использование сканера веб-приложений, такого как DeepScan от Acunetix, значительно повысит скорость и точность, с которой разработчики и специалисты по безопасности могут обнаруживать уязвимости, такие как DOM XSS, и исправить их, а также тысячи других.

 

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!
Добавить комментарий

  1. Pavel5

    У меня начальство после нескольких инцидентов перестало забивать на безопасность и поручило пентест сторонним спецам. Недешево конечно, зато потом спокойнее. Сейчас кстати много кто таким занимается. Наши в ****** обращались, т.к. их офис недалеко от нашего, но есть и другие

    Ответить