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

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

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

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

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

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

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

HttpUtility.HtmlEncode и сервер. HtmlEncode не препятствует межсайтовому скриптингу

Однако это, по мнению автора. Лично не тестировал.

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

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

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

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

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

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

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

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

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

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

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