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

Question

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

Зачем мне использовать AntiXss.HtmlEncode вместо HttpUtility.HtmlEncode?

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

• Белый список вместо подхода черного списка
• Улучшение производительности на 0,1 мс

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

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

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

Answer 1

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

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

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

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

Редактировать - Добавлено

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

HttpUtility.HtmlEncode и Server. HtmlEncode не запрещает межсайтовый скриптинг

Хотя, по мнению автора. Я не проверял это лично.

---

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

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

Answer 2

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

Answer 3

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

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

2. Список белых (или безопасных) символов Библиотеки Анти-XSS поддерживает более десятка языков (греческий и коптский, кириллический, кириллический, армянский, иврит, арабский, сирийский, арабский, тхана, нко и т. Д.). больше)

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

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

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

Answer 4

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

Answer 5

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