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

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


    Атаки 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 работают заметно медленнее своих собратьев и использовать их имеет смысл только там, где ставятся повышенные требования к безопасности.

    Похожие публикации

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 5 314 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 4

      0
      Разнообразили вы мои знания о защите от XSS, хотя в проекте, над которым я сейчас работаю HttpUtility-вполне достаточно.Но..надо не забыть на будущее, спасибо!
        +1
        Пробовал использовать давно, полностью не понравилось. HtmlEncode решает все проблемы.
        Если у вас .NET 3.5 то сделайте типу String метод HtmlEnc для удобства :-)
        А, и еще. У тега Literal есть атрибут Mode, его можно выставлять в режим Encode.

        Удачи!
          +1
          Мне тоже не понравилось, но из-за производительности о чем я и попытался рассказать в статье :)
          0
          А можно ли как-то пропустить безопасные теги
          и тд?

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

          Самое читаемое