ASP.NET MVC 2 - AntiXSS против встроенной кодировки MVC

Question

Теперь, когда MVC ввел кодировку HTML через

<%: blah %> 

есть ли еще значение в использовании

<%= AntiXSS.HTMLEncode(blah) %> 

вместо

Например: мое приложение будет принимать весь контент (включая JavaScript) и сохранять его в исходном состоянии в базе данных. Я планировал просто вывести все, используя что-то вроде <%: model.Name %> и полагаясь на MVC "вещи", чтобы сделать кодирование для меня.

Достаточно ли безопасен этот метод, чтобы на него можно было положиться для AntiXSS, или мне нужно явно использовать библиотеку AntiXSS? Если мне нужно использовать библиотеку AntiXSS, могу ли я спросить, почему такого рода вещи уже не встроены в MVC?

Answer 1

Не думаю, что есть какая-то реальная разница, но если вы действительно заинтересованы, вы можете использовать библиотеку AntiXss в качестве кодировщика по умолчанию для asp.net, как описано в этой статье .

Answer 2

<%: кодирует только с <a href="http://weblogs.asp.net/scottgu/archive/2010/04/06/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2.aspx" rel="nofollow noreferrer"> кодировкой HTML . Если вы выводите в атрибуты HTML, Javascript или любое другое пространство, где применяются правила тела HTML, вам все равно придется выбирать метод кодирования вручную.

Answer 3

Согласно статье Фила Хаака: Используя AntiXss в качестве кодера по умолчанию для ASP.NET в ASP.NET 4 (включая MVC), вы можете переопределить кодер HTML по умолчанию для использования кодера AntiXSS.

Причины против "AntiXSS.HTMLEncode" 1) Сокращения легче кодировать 2) Вызов вспомогательного метода (<%:%> / @: / HttpUtility.HtmlEncode / Server.HtmlEncode / etc.) И внедрение реализации кодировщикаделает ваш код более понятным по сравнению с конкретной реализацией AntiXSS.

Однако я считаю, что «AntiXSS.HTMLEncode» - единственный вариант для версий .NET <4 </p>