Подавление кодов ответа HTTP 500 - PullRequest
2 голосов
/ 10 февраля 2010

У меня было немного отзывов от некоторых людей об угрозах и уязвимостях, связанных с сайтами, возвращающими коды ответа HTTP 500. По сути, совет состоит в том, чтобы были приняты все возможные меры, чтобы сервер не выбрасывал 500 (т. Е. Обширная проверка ввода формы), что вполне нормально.

Однако совет также предполагал, что попытки поставить под угрозу безопасность с помощью таких средств, как вставка тега в произвольную строку запроса, вызывающая срабатывание проверки запроса ASP.NET или манипулирование состоянием представления, также не должны возвращать HTTP 500. Очевидно, что поведение встроенной платформы интерпретировать запрос и, возможно, перебросить его на пользовательскую страницу ошибки, но даже это вернет код ответа 500.

Так что я после некоторых мыслей о том, как подойти к этому. Есть ли способ настроить приложение на уровне .NET или IIS для возврата HTTP 200 при поднятии 500? Или это станет упражнением в кодировании на уровне global.asax в одном из событий приложения? Есть ли другие последствия для рассмотрения?

Кстати, с точки зрения безопасности обоснование заключается в том, что приложения, которые возвращают HTTP 500, могут рассматриваться ботами как «низко висящие плоды», которые случайным образом сканируют уязвимости и вызывают дальнейшую вредоносную активность. Попытки лично меня не убедить, что изменение кодов ответов дает какие-либо реальные преимущества в плане безопасности, но я рад, что воспользовался советом профессионалов.

Ответы [ 3 ]

4 голосов
/ 10 февраля 2010

Чтобы ответить на ваш вопрос : global.asax - это правильное место, в частности, обработчик события Application_Error. Вы должны быть в состоянии сделать что-то вроде

Response.StatusCode = 200
Response.StatusDescription = "OK"

есть.

PS : Не делай этого. :-) Для меня это звучит как еще один подход, основанный на принципах «безопасность за мраком за нарушение». Я действительно не думаю, что (возможно, незначительное) повышение безопасности стоит нарушать правильное поведение HTTP (подумайте о том, как Google индексирует ваши страницы ошибок и т. Д.).

4 голосов
/ 10 февраля 2010

Почему? Отправка кода 500 без какой-либо другой информации не дает злоумышленнику много информации.

Если вы не выбрасываете трассировку стека, дампы состояния и т. Д. Обратно клиенту, тогда все в порядке. И я очень сомневаюсь, что ты хочешь это сделать.

Серьезно, просто создайте страницу "500" (изображение кита необязательно) и верните ее с вашим статусом 500 - это ничего не даст.

Отправка статуса 200, когда страница НЕ была успешно создана, является ошибочной и может привести к тому, что произойдет что-то плохое - например, боты, считающие страницу подлинной. Вы не хотите, чтобы ваша страница с ошибкой 500 отображалась в Google, потому что вместо этого вы вернули статус 200.

1 голос
/ 10 февраля 2010

Вы можете установить пользовательские страницы ошибок в конфигурации - и вы можете повторно установить статус ответа на своей пользовательской странице ошибок

<customErrors  mode="On" defaultRedirect="~/DefaultErrorPage.htm" >
  <error statusCode="500" redirect="~/CustomError.aspx"/>
</customErrors>

Серьезное предупреждение ...!

Убедитесь, что на вашей пользовательской странице ошибок никогда не было ошибок. Обычно вы используете html-страницу, а не aspx-страницу, но если вы хотите изменить заголовки ответа, вам может понадобиться использовать aspx-страницу. Ничего другого не делайте, кроме изменения заголовков (то есть не выводите данные из базы данных или не пытайтесь запустить какую-либо логику), и ошибка на вашей пользовательской странице ошибок приведет к ошибке «максимальное количество перенаправлений». *

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...