Pull to refresh

asp.net: Microsoft Anti-Cross Site Scripting Library еще один способ защиты от XSS-атак

Reading time 4 min
Views 3.1K

Небольшое введение.


Атаки XSS (cross-site scripting) на веб-ресурсы не зависят от платформы, среды разработки, веб-сервера или языка программирования. Основа успеха при этой атаки смешивание кода и данных, когда на сайте данные контента формируются в коде, как, например, в следующем примере:

Label1.Text = userName;

С виду все хорошо, но до той поры пока пользователь при регистрации в поле имени не введет строку типа:
<script>alert('attack!');</script>* This source code was highlighted with Source Code Highlighter.

Хорошо, что asp.net обладает защитой по умолчанию и проверяет любой запрос на наличие опасных значений. Если на странице не вставить параметр ValidateRequest=«false», то шансов вбить в поле ввода опасное значение у злоумышленника практически не будет.
Частенько требуется позволить пользователю передавать на сервер данные с тэгами или html-фрагменты. В таком случае параметр ValidateRequest отключают и безопасность ресурса попадает под удар. Скажем, имеем такой код:
Label1.Text = Request.QueryString[«name»] ?? «Пусто»;

Злоумышленник вполне может послать такой запрос незащищенной странице:
httр://some.domain/default.aspx?name= %3D%3C%73%63%72%69%70%74%3E%78%3D%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3B%61%6C%65%72%74%28%78%29%3B%3C%2F%73%63%72%69%70%74%3E


При выключенной проверке на безопасность строки запроса asp.net пропустит такую строку и в результате элемент управления выведет в странице небезопасную строку:
<script>x=document.cookie;alert(x);</script>* This source code was highlighted with Source Code Highlighter.


Стандартные способы защиты.


В asp.net есть несколько статических методов для предотвращения XSS-атак, все они объединены в класс HttpUtility:
— HtmlEncode – кодирует строку в безопасную для размещения на странице;
— HtmlAttributeEncode – кодирует строку в безопасную для размещения на странице, но не обрабатывает целый массив символов, например не конвертирует “>” в >
— UrlEncode – кодирует строку url в безопасную, заменяя опасные символы на коды, например «<» и «>» кодируются как «%3c» и «%3e».
Я не стану расписывать что и как делают эти методы, а перейду сразу к причине написания статьи.

Библиотека Microsoft Anti-Cross Site Scripting Library.


Микрософт в рамках проекта Sandbox предлагает альтернативный подход к защите от XSS-атак. Библиотека Anti-Cross Site Scripting Library (далее AntiXSS) предлагает следующие методы:
— HtmlEncode, HtmlAttributeEncode и UrlEncode – повторяют функционал методов HttpUtility;
— JavaScriptEncode – кодирует строку с блоком javascript-кода;
— VisualBasicScriptEncode кодирует строку с блоком vbscript-кода;
— XmlEncode — кодирует строку для использования в XML;
— XmlAttributeEncode — кодирует строку для использования в XML-атрибутах;

В чем же отличие данного решения от стандартного? На странице проекта в разделе FAQ различие описывается так: «Библиотека Microsoft Anti-Cross Site Scripting Library отличается от этих методов тем, что использует принцип техники включения, который первым делом определяет набор допустимых символов, отличные от которого автоматически кодируются». В документации к проекту можно узнать набор символов, которые не кодируются:
— a-z, A-Z;
— 0-9;
— запятая, точка, дефис, подчеркивание;
— пробел кодируется всеми функциями кроме следующих: HtmlAttributeEncode, UrlEncode, XmlAttributeEncode.

Все остальные символы подлежат кодированию. Причем, если методы HttpUtility кодируют симовол «<» в &lt, то AntiXSS кодирует «<» в «&#60;». Точно так же дела обстоят с кавычками, амперсантом и другими символами.
Данный подход в чем-то является избыточным, но в вопросах безопасности в наше время избыточность порой даже приветствуется. И если большинство пользователей вполне довольны стандартным инструментом HttpUtility, то крупные компании или веб-ресурсы оперирующие секретными данными вполне могут перейти на AntiXSS для обеспечения максимальной защиты в таком вопросе как XSS-атаки.

Вопросы производительности.


Избыточность безопасности – это конечно хорошо, но как обстоит дело с производительностью? Проверим производительность самым простым способом:
DateTime date1, date2;
date1 = DateTime.Now;

for (int j = 1; j <= 100000; j++)
HttpUtility.HtmlEncode(attack);

date2 = DateTime.Now;
Label1.Text = (date2 - date1).ToString();

date1 = DateTime.Now;

for (int j = 1; j <= 100000; j++)
AntiXss.HtmlEncode(attack);

date2 = DateTime.Now;
Label2.Text = (date2 - date1).ToString();


Результаты не радуют:

— Если присвоить attack сложную строку типа
«Этот текст используется чтобы проверить скорость обработки опасного выражения . Добавим к строке еще и текста написанного в таком виде %3D%3C%73%63%72%69%70%74%3E%78%3D%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3B%61%6C%65%72%74%28%78%29%3B%3C%2F%73%63%72%69%70%74%3E»
то результаты будут такими: HttpUtility -00:00:00.4143216 AntiXSS — 00:00:05.8486560;

— Если attack присвоить строку попроще
«%3D%3C%73%63%72%69%70%74%3E%78%3D%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3B%61%6C%65%72%74%28%78%29%3B%3C%2F%73%63%72%69%70%74%3E»
, то результаты 00:00:01.5328896 в случае использования AntiXSS и 00:00:00.0351120 в случае с HttpUtility.

— Если attack присвоить просто
«Этот текст используется чтобы проверить скорость обработки опасного выражения .»
, то результаты будут такими: HttpUtility = 00:00:00.1976304 и AntiXSS = 00:00:02.8270176;

— В самом простейшем случае attack =
«»
HttpUtility = 00:00:00.1123584 AntiXSS = 00:00:00.4353888.
Как видно, отрыв очень велик и, как ожидалось, избыточность безопасности достигается в ущерб производительности.

Выводы.


Microsoft Anti-Cross Site Scripting Library предлагает функционал для предотвращения XSS-атак, который по сравнению с HttpUtility предлагает изыбточную безопасность. Вместе с тем, методы AntiXSS работают заметно медленнее своих собратьев и использовать их имеет смысл только там, где ставятся повышенные требования к безопасности.
Tags:
Hubs:
+11
Comments 4
Comments Comments 4

Articles