Проверка запроса ASP.NET с использованием символов в кодировке HTML

Question

У меня есть текстовое поле в форме, которое должно принимать входные данные с тегами HTML.

При отправке входных данных с тегами HTML приложение выдает HttpRequestValidationException, если только мы не используем HttpUtility.HtmlEncode.Пока все просто.

Однако на входе могут также содержаться символы, такие как символ «градусы» (°).Когда они также кодируются в формате HTML, они становятся цифровыми управляющими кодами, в этом примере °.Эти коды также приводят к выбрасыванию HttpRequestValidationException, но возникает вопрос, почему?

Я не понимаю, почему числовые escape-коды считаются потенциально опасными, особенно если ° прекрасно работает как ввод.

Кажется, я застрял, так как оставить входные данные как есть не удается из-за тегов, а HTML-кодирование ввода не выполняется из-за числовых экранировок.Мое решение до сих пор заключалось в кодировании HTML, а затем в регулярном выражении замены escape-последовательностей их декодированными HTML-формами, но я не уверен, является ли это безопасным решением, поскольку я предполагаю, что escape-последовательности рассматриваются как опасные по определенной причине.1014 *

Answer 1

ASP.NET считает, что экранирование html-символов (& # xxx) опасно по той же причине, по которой угловая скобка опасна, то есть XSS. Используя вышеуказанный escape, вы можете включить любой символ (например, угловая скобка). Вот сводка того, что проверка запросов делает в 1.1 и 2.0.

В законных случаях, таких как ваше дело, вы можете выбрать любой из нижеуказанных

1. Выберите свою собственную обработку, как описано вами
2. Отключить проверку запроса на странице уровень (<% @ Page ValidateRequest = "ложь") </li>
3. В .NET 4 замените собственную проверку запроса, используя RequestValidator class.

Answer 2

Это связано со встроенными возможностями проверки ASP.NET Межсайтовый скриптинг . Вот какой-то список того, что разрешено, а что нет в ASP.NET, здесь, на SO: Причины проверки запроса ASP.NET: есть ли список?

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

Answer 3

Просто добавьте в вашу директиву страницы (первая строка страницы) этот атрибут:

ValidateRequest = "false"

Answer 4

Я бы посоветовал заняться ограниченным html-кодированием на стороне клиента, что довольно просто для jquery, связывая обработку с отправкой формы.

Что я имею в виду под «ограниченным»?Амперсанды, угловые скобки и кавычки должны быть закодированы, но не символы Unicode.Вы указываете на то, что на самом деле числовые escape-коды являются злыми и отклоняются, в отличие от их неэкранированных эквивалентов!

Вы можете запустить отправляемую строку с помощью функции javascript, аналогичной приведенному ниже коду, даваязначение, которое прошло бы проверку запроса:

function safeString(s) {
    return s.replace(/&/g,"&amp;").replace(/</g,"&lt;").replace(/>/g,"&gt;").replace(/"/g, "&quot;");
}

Это может вызвать у вас горе, если после сохранения или выполнения какой-либо серверной магии с переданным значением вы захотите повторно отобразить его внутривход.Позвольте мне уточнить: если вы просто поместите строку, закодированную таким образом, в пустой абзац, она будет прекрасно отображаться;однако, если вы сбросите его в текстовое поле, вы увидите <</strong> вместо <</strong>

Как ни странно, при написании последнего предложения мне пришлось набрать & lt; и <</strong> соответственно ...

Answer 5

Вы можете прочитать Обзор сценариев в справке msdn.

Если вы уверены, что обрабатываете любой возможный ввод вредоносного кода на своей странице, вы можете отключить проверку с использованием директивы <% @ Page validateRequest = "false"%>.