2010-09-20 2 views
1

Мы бежим сайт с примерно 6000-7000 посетителей в Интернете одновременно (это, чтобы указать размер)Отключение ASP.Net Request.Path Validation

переключившись с ASP.Net 3,5 до 4,0 мы внезапно столкнуться с их масса:

Потенциально опасное значение Request.Path было обнаружено у клиента (>).

Они все поврежденные URL-адреса и, по-видимому, содержат какой-то HTML или javascript, которые были добавлены в действительный URL.

Например у нас есть один такой:

/UI/Формы/Users/Фотографии/функция (значение) {вар результат = NULL; for (var i = 0; i < this.length; i ++) {if (this [i] === val) {result = this [i]; this.splice (я

Как вы можете видеть, что это относительный URL, и он действителен до/Фотографии /. Однако функции (VAL) и т.д., является функцией от prototype.js, который обычно включен на страница

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

Поэтому я полагаю, что у нас есть другие варианты, кроме как отключить проверку - так что вопрос в том, как именно?

Я не хочу отключать проверку запроса полностью, так как это также отключает проверку размещенных значений формы.

Большое спасибо за любую помощь заранее :-)

ответ

3

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

<httpRuntime requestValidationMode="2.0" /> 

Это отключит проверку запроса на страницах с пометкой ValidateRequest="false". В ASP.NET 4.0 вам нужен этот атрибут, или даже если вы отключите проверку запроса страницы, вы получите исключения.

Если, с другой стороны, эти исключения являются атаками вашего сайта, тогда просто ничего не делают и оставляют инфраструктуру ASP.NET этими опасными запросами.

+0

Я забыл упомянуть, что я уже установил это: -/Однако эта функциональность определенно не является частью сайта, - но обычные пользователи, честно говоря, недостаточно умны, чтобы выполнять атаки XSS, поэтому я думаю, что это какая-то проблема с браузером. – Steffen

+0

Обычные пользователи могут быть недостаточно умны для выполнения XSS-атак, но достаточно умны, чтобы ввести '<' в поле ввода адреса, например. –

+0

Хе-х истинно, однако скрипт, включенный в URL-адрес, представляет собой небольшую часть prototype.js, поэтому я сомневаюсь, что он исходит от пользователей. Как он попадает в URL-адрес, я понятия не имею. – Steffen