Проверка правильности инъекции JavaScript DOM XSS

Question

Достаточно ли этого регулярного выражения, чтобы перехватывать все попытки межсайтового скриптинга при внедрении HTML в DOM. Например: например, с document.write ()

(javascript:|<\s*script.*?\s*>)

На него ссылаются в этом документе от modsecurity.com http://www.modsecurity.org/documentation/Ajax_Fingerprinting_and_Filtering_with_ModSecurity_2.0.pdf

Будет ли он перехватывать все <\ s <em>script. ? \ S *> варианты в UTF-8, например?

Answer 1

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

<img src="blah.jpg" alt="" onmousedown="alert('a')" />

Проверьте здесь (несколько устарело, но все понятно) и здесь для дополнительных примеров

Answer 2

Другие респонденты правы: существует много контекстов, через которые может произойти инъекция. Помните, решение должно учитывать оба контекста, в которых может произойти инъекция. Подход черного фильтра (или «известный как плохой») к фильтрации не сработает, поскольку он становится жертвой атак, которые кодируют инъекции с использованием неожиданных наборов символов, творческого использования пробелов и других методов. Для получения дополнительной информации см. OWASP DOM Based XSS . Ссылки на этой странице рассказывают о проблемах.

Что касается решения, рассмотрите Шпаргалку по профилактике OWASP XSS DOM , которую мы только что опубликовали. В Шпаргалке есть несколько наборов инструментов, которые помогут вам реализовать стратегии экранирования или кодирования. Вероятно, МОЙ ЛЮБИМЫЙ подход к обеспечению того, чтобы серверный код, написанный на сервере, кодировался и экранировался соответствующим образом, был JXT . С его кодовой страницы Google:

<!-- Automatically escaped content -->
Hello ${user.getName()}!

<!-- Example tag with 3 different contextual encoding requirements -->
<img src="/profile-photo?user=${user.getId()}"
     alt="Photo of ${user.getName()}"
     onclick="openProfile('${user.getId()}')" />

<!-- Override the default escape, rare, but occasionally needed: -->
<jxt:out value="${user.getProfileHtml()}" escape="none"/>

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

Answer 3

Достаточно ли этого регулярного выражения для перехвата всех попыток межсайтового скриптинга? 1002 *

Hahahahahahahahahaha.

Извините. Но на самом деле ... нет, это даже не верхушка айсберга.

Даниэль упомянул еще один метод введения сценария, но на самом деле их сотни. Совсем не возможно очистить HTML с помощью простого регулярного выражения. Единственный подход (и даже тогда он не тривиален) заключается в том, чтобы правильно проанализировать HTML, отбрасывая все искаженные последовательности и имена элементов / атрибутов, за исключением нескольких известных безопасных.

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

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