В чем разница между AntiXss.HtmlEncode и HttpUtility.HtmlEncode?

Я просто столкнулся с вопросом с ответом, предлагающим библиотеку AntiXss избежать межсайтового скриптинга. Звучит интересно, читая msdn blog, похоже, просто предоставляет метод HtmlEncode(). Но я уже использую HttpUtility.HtmlEncode().

Почему я хочу использовать AntiXss.HtmlEncode через HttpUtility.HtmlEncode?

В самом деле, я не первый, кто задал этот вопрос. И, действительно, Google открывает несколько ответы, в основном

  • Белый список вместо подхода черного списка
  • Повышение производительности за 0.1 мс

Хорошо, это хорошо, но что это значит для меня? Меня не волнует производительность 0,1 мс, и мне действительно не хочется загружать и добавлять другую библиотечную зависимость для функциональности, которую у меня уже есть.

Есть ли примеры случаев, когда реализация AntiXss предотвратила бы атаку, которой не была реализована реализация HttpUtility?

Если я продолжу использовать реализацию HttpUtility, я рискую? Что насчет этой "ошибки" ?

ОТВЕТЫ

Ответ 1

У меня нет ответа конкретно на ваш вопрос, но я хотел бы указать, что белый список против черного списка подходит не просто "хорошо". Это важно. Очень важно. Когда дело доходит до безопасности, каждая мелочь важна. Помните, что при использовании межсайтового скриптинга и подделки подпроса сайта, даже если ваш сайт не показывает конфиденциальные данные, хакер может заразить ваш сайт вводя javascript и использовать его для получения конфиденциальных данных с другого сайта. Поэтому делать это очень важно.

Рекомендации OWASP определяют с использованием подхода белого списка. Рекомендации PCI Compliance также определяют это в стандартах кодирования (поскольку они относятся к его рекомендациям OWASP).

Кроме того, новая версия библиотеки AntiXss имеет приятную новую функцию:.GetSafeHtmlFragment(), которая хороша для тех случаев, когда вы хотите хранить HTML в базе данных и показывать ее пользователю как HTML.

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

Изменить - добавлено

Как задано в вопросе, пример того, где анти-xss будет защищать вас и HttpUtility, не будет:

HttpUtility.HtmlEncode и Server. HtmlEncode не предотвращает создание скриптов на разных сайтах

Это, по мнению автора, все же. Я лично не тестировал его.

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

В настоящий момент HttpUtility.HtmlEncode может успешно блокировать каждую атаку, просто удаляя/кодируя < и >, а также несколько других "известных потенциально опасных" символов, но кто-то всегда пытается подумать новых способов взлома. Разрешить только известный безопасный (белый список) контент намного проще, чем пытаться думать обо всех возможных небезопасных бит ввода, которые злоумышленник может бросить на вас (подход черного списка).

Ответ 2

С точки зрения того, почему вы используете один над другим, считайте, что библиотека AntiXSS выпущена чаще, чем структура ASP.NET, поскольку, как говорит Дэвид Стрэттон, "кто-то всегда пытается думать о новых способах взлома в ', когда кто-то придумал, у библиотеки AntiXSS гораздо больше шансов получить обновленный релиз для защиты от него.

Ответ 3

Ниже приведены различия между методами Microsoft.Security.Application.AntiXss.HtmlEncode и System.Web.HttpUtility.HtmlEncode:

  • Anti-XSS использует технику белого листинга, иногда называемую принципом включения, для обеспечения защиты от атак типа Cross-Site Scripting (XSS). Этот подход работает, сначала определяя допустимый или допустимый набор символов, и кодирует что-либо вне этого набора (недопустимые символы или потенциальные атаки). System.Web.HttpUtility.HtmlEncode и другие методы кодирования в этом пространстве использования используют принцип исключений и кодируют только определенные символы, обозначенные как потенциально опасные, такие как символы <, > и и.

  • Список белых (или безопасных) библиотек Anti-XSS поддерживает более десятка языков (греческое и коптское, кириллическое, кириллическое приложение, армянское, иврит, арабское, сирийское, арабское приложение, Thaana, NKo и подробнее)

  • Библиотека Anti-XSS была разработана специально для уменьшения атак XSS, тогда как методы кодирования HttpUtility создаются для обеспечения того, чтобы выход ASP.NET не нарушал HTML.

  • Производительность - средняя дельта между AntiXss.HtmlEncode() и HttpUtility.HtmlEncode() составляет +0,1 миллисекунды за транзакцию.

  • Anti-XSS Version 3.0 предоставляет тестовую проводку, которая позволяет разработчикам запускать проверку и проверку производительности XSS.

Ответ 4

Большинство уязвимостей XSS (любой тип уязвимости, фактически) основаны исключительно на том факте, что существующая безопасность не "ожидала" определенных вещей. По умолчанию только белые списки подходят для обработки этих сценариев.

Ответ 5

Мы используем белый список для сайтов Microsoft Windows Live. Я уверен, что есть несколько атак безопасности, о которых мы еще не думали, поэтому мне больше нравится параноидальный подход. Я подозреваю, что были случаи, когда в "черном списке" были обнаружены уязвимости, которых не было в "белом списке", но я не мог рассказать вам подробности.