ASP.NET customErrors web.config не улавливает все недопустимые URL-адреса

Похоже, есть ошибка в перенаправлении customErrors по умолчанию в web.config. В моем файле web.config у меня есть следующий параметр customErrors

<customErrors defaultRedirect="~/generalerror.html?" mode="On" />

Насколько мне известно, это должно отправлять все ошибки на настраиваемую страницу generalerror.html. Кажется, это работает для некоторых недопустимых URL-адресов, например

http://website.com/?x="<p>"
http://website.com/"<p>"

НО это не работает, если в URL-адресе используется «&» и нет «?» и есть тег HTML. Так что это

http://website.com/&x="<p>"

полностью игнорирует customErrors, и вы получаете желтую ошибку времени выполнения по умолчанию вместо отправки на настраиваемую страницу generalerror.html. Как мне сделать так, чтобы этот URL-адрес также был перенаправлен на настраиваемую страницу ошибки?

Если я выключу mode = "Off" в web.config, я получу следующую ошибку

A potentially dangerous Request.RawUrl value was detected from the client (="/&x="<p>"").

asp.net web-config custom-error-pages
person user2986086    schedule 04.12.2013    source источник
comment
HTH! stackoverflow.com/questions/10837647/ stackoverflow.com/questions/9498180/ Вы должны помнить, что это исключение возникает раньше вас. код страницы бывает. Таким образом, вы обычно не можете обнаружить ошибку в коде вашей страницы, а только в Application_Error.   -  person Joe    schedule 04.12.2013
comment
В настоящее время я ничего не делаю на уровне кода, но спасибо за ссылки. Я просто использую тег клиентских ошибок web.config для перенаправления ошибок на определенную страницу. Это должно работать из того, что я прочитал. На самом деле, насколько я могу судить, это действительно работает, за исключением очень конкретного примера, который я привел. Мне просто нужно выяснить, почему это не работает в этом одном случае   -  person user2986086    schedule 05.12.2013
comment
Если вы используете IIS7 +, здесь есть более простое решение: - stackoverflow.com/questions/30071341/   -  person Iain Galloway    schedule 06.05.2015

Ответы (1)


arrow_upward
0
arrow_downward

Поскольку вы передаете HTML-теги в URL-адресе, это может указывать на атаку межсайтового скриптинга. Не все теги HTML опасны, но когда за символами HTML следуют определенные символы, такие как '&' в вашем случае, asp.net рассматривает это как атаку межсайтового скриптинга и не разрешает ее по умолчанию.

Вам следует подумать о кодировании URL-адреса, чтобы обойти это. И это всегда лучшая практика. Вот хорошее объяснение насчет XSS. И здесь - ссылка, в которой подробно объясняется, как решить эту проблему.

Чтобы изменить это поведение, вы можете установить для проверки запроса значение false в web.config.

<configuration>
<system.web>
    <pages validateRequest="false" />
</system.web>
</configuration>

Но в этом случае запросы необходимо подтверждать на страницах.

Критические изменения были внесены в проверку запросов ASP.NET в .NET 4.0, и эта запись требуется для возврата к .NET 2.0, когда недопустимые URL-адреса будут перенаправлять на настраиваемую страницу ошибки.

<httpRuntime requestValidationMode="2.0" />
person Poornima    schedule 04.12.2013
comment
Существуют потенциальные хакеры и клиенты, которые пытаются опубликовать недействительные URL-адреса, и мне нужно убедиться, что они отправили их на ту же страницу с ошибкой, чтобы они выглядели одинаково. Я не хочу отключать проверку. Я просто хочу отправлять эти запросы на мою страницу с ошибками, когда они происходят. - person user2986086; 04.12.2013
comment
Да, если вы отключите проверку, вам необходимо проверить запрос на странице, где вы можете перенаправить его на страницу с ошибкой, если это недействительный запрос. См. Эту ссылку stackoverflow.com/questions/20009815/ - person Poornima; 05.12.2013
comment
Добавление requestValidationMode = 2.0 в тег httpRuntime позволяет правильно обработать упомянутый мной URL. Так что спасибо за помощь - person user2986086; 05.12.2013