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

Раздел: Programming / ASP.NET @ 15.05.2008 | Ключевые слова: xss. asp.net атака

Автор: XaocCPS
Источник: habrahabr

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

Атаки 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 сложную строку типа

«Этот текст используется чтобы проверить скорость обработки опасного выражения <script>alert(`attack!`);</script>. Добавим к строке еще и текста написанного в таком виде %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 присвоить просто

«Этот текст используется чтобы проверить скорость обработки опасного выражения <script>alert(`attack!`);</script>.»

, то результаты будут такими: HttpUtility = 00:00:00.1976304 и AntiXSS = 00:00:02.8270176;

- В самом простейшем случае attack =

«<script>alert(`attack!`);</script>»

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

Выводы.

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

Это интересно:

Атаки конкурентов, способные нанести вред вашему сайту: Атака на DNS

Изоляция служб в Windows

Распечатать статью