Вопрос:

От клиента было обнаружено потенциально опасное значение Request.Form

asp.net asp.net-mvc validation html-encode

874436 просмотра

30 ответа

14469 Репутация автора

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

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

Отслеживание исключения и отображение

Произошла ошибка. Вернитесь и введите заново всю форму, но на этот раз не используйте <

не кажется мне достаточно профессиональным.

Отключение post validation ( validateRequest="false") определенно позволит избежать этой ошибки, но сделает страницу уязвимой для ряда атак.

В идеале: когда происходит обратная запись, содержащая ограниченные символы HTML, это опубликованное значение в коллекции Form будет автоматически кодироваться в формате HTML. Таким образом, .Textсвойство моего текстового поля будетsomething & lt; html & gt;

Есть ли способ, которым я могу сделать это из обработчика?

Автор: Radu094 Источник Размещён: 17.09.2008 10:58

Ответы (30)


45 плюса

18761 Репутация автора

Вы можете кодировать содержимое текстового поля HTML , но, к сожалению, это не остановит исключение. По моему опыту нет никакого пути, и вы должны отключить проверку страницы. Делая это, вы говорите: «Я буду осторожен, я обещаю».

Автор: Pavel Chuchuva Размещён: 17.09.2008 11:20

1027 плюса

34678 Репутация автора

Решение

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

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

Кроме того, " <" не является опасным по своей природе. Это опасно только в определенном контексте: при написании строк, которые не были закодированы в вывод HTML (из-за XSS).

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

Суть в том, что вы не можете отфильтровать случайный ввод для опасных символов, потому что любой символ может быть опасным при правильных обстоятельствах. Вы должны кодировать в точке, где некоторые конкретные символы могут стать опасными, потому что они переходят на другой язык, где они имеют особое значение. Когда вы пишете строку в HTML, вы должны кодировать символы, которые имеют особое значение в HTML, используя Server.HtmlEncode. Если вы передаете строку в динамический оператор SQL, вы должны кодировать разные символы (или, лучше, позвольте платформе сделать это за вас, используя подготовленные операторы или тому подобное) ..

Когда вы уверены, что HTML-кодирование везде, вы передаете строки в HTML, а затем установите validateRequest="false"в <%@ Page ... %>директиве в ваших .aspxфайлах.

В .NET 4 вам может потребоваться сделать немного больше. Иногда необходимо также добавить <httpRuntime requestValidationMode="2.0" />в web.config ( ссылка ).

Автор: JacquesB Размещён: 17.09.2008 11:26

12 плюса

46459 Репутация автора

Я думаю, вы могли бы сделать это в модуле; но это оставляет открытыми некоторые вопросы; Что делать, если вы хотите сохранить входные данные в базе данных? Внезапно, поскольку вы сохраняете закодированные данные в базе данных, вы в конечном итоге доверяете вводу данных, что, вероятно, является плохой идеей. В идеале вы храните необработанные незакодированные данные в базе данных и каждый раз кодируете.

Отключение защиты на уровне страницы и последующее кодирование каждый раз является лучшим вариантом.

Вместо использования Server.HtmlEncode вы должны взглянуть на более новую, более полную библиотеку Anti-XSS от команды Microsoft ACE.

Автор: blowdart Размещён: 17.09.2008 11:26

4 плюса

11558 Репутация автора

Пока это только символы "<" и ">" (а не сами двойные кавычки), и вы используете их в контексте, например, , вы в безопасности (тогда как для