В чем разница между 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 предназначена для использования в качестве инструмента, а не замены знаний.Полагаться на то, что библиотека сделает это правильно за вас, - все равно что ожидать, что действительно хорошая кисть позволит создавать хорошие картины без хорошего художника.

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

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

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

Впрочем, это по словам автора.Я не тестировал это лично.

---

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

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