Достаточно ли экранирования для блокирования XSS-атак?

#javascript #asp.net #xss

Вопрос:

Я уверен, что ответ на этот вопрос отрицательный, но, похоже, я не могу найти способ, который простым преобразованием < и > в amp;< и amp;> не полностью блокирует отраженный и постоянный XSS.

Я не говорю о CSRF.

Если это не блокирует XSS, можете ли вы привести пример того, как обойти эту защиту?

Ответ №1:

Не все XSS-атаки вообще включают <или> , в зависимости от того, куда вставляются данные.

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Why_Can.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F

Ответ №2:

При использовании ненадежной строки в атрибуте (заключенной в " кавычки) вам необходимо экранировать " как amp;quot .

В противном случае вы могли бы легко внедрить javascript. Например, <a href="{{str}}"> с str значением, например, " onmouseover='something-evil'" .

1. В последнем случае используйте кодировку URL, а не HTML-объекты; в этом случае " становится просто " .

2. Вы не можете просто закодировать в URL весь URL-адрес, поскольку это также нарушило бы строки запроса.

3. Ах, так побег «, <, и > заблокировал бы простой ответ. Ошибка записи (ввода), но если бы у меня был существующий блок скрипта или встроенные элементы DOM с прямым пользовательским вводом, где < и> не были необходимы для запуска ввода, я все равно был бы уязвим.

4. В этом примере требуется кодировка вывода HTML или, более конкретно, кодировка вывода атрибута HTML. Кодировка URL предназначена для строк, добавляемых к URL, таких как строки запроса, в противном случае ваш атрибут href будет выглядеть как «http://www». В подобном примере Encoder. HtmlAttributeEncode из библиотеки AntiXSS — это то, что вы действительно ищете.

Ответ №3:

Нет. Вот пара примеров, когда экранирования < , > , ' " и amp; недостаточно:

Пример 1:

 <a href="{{myUrl}}">

XSS-атака:

 myUrl = "javascript:alert(1)"

Пример 2:

 <script>var page = {{myVar}};</script>

XSS-атака:

 myVar = "1;alert(1)"

Смотрите https://www.owasp.org/index.php/XSS_ (Cross_Site_Scripting)_Prevention_Cheat_Sheet для способов предотвращения этих атак.

Ответ №4:

Нет, этого недостаточно. Помните, что XSS — это не только ненадежные данные в HTML, вы также найдете их в JavaScript и CSS. Подумайте о такой ситуации, как «var myVar = [input];» С этим [входным] значением можно проделать множество вредоносных действий, не приближаясь к угловым скобкам. В XSS-шпаргалке есть еще много примеров:http://ha.ckers.org/xss.html

Вы упомянули ASP.NET в теге; то, на что вы хотите обратить внимание, это [AntiXSS library][1] . Возьмите это и используйте соответствующую кодировку вывода:

 Encoder.CssEncode()
Encoder.HtmlEncode()
Encoder.HtmlAttributeEncode()
Encoder.JavaScriptEncode()

и т.д. и т.п. Нет абсолютно никакой причины пытаться выполнить собственную замену символов в .NET.