У меня было немного отзывов от некоторых людей об угрозах и уязвимостях, связанных с сайтами, возвращающими коды ответа HTTP 500. По сути, совет состоит в том, чтобы были приняты все возможные меры, чтобы сервер не выбрасывал 500 (т. Е. Обширная проверка ввода формы), что вполне нормально.
Однако совет также предполагал, что попытки поставить под угрозу безопасность с помощью таких средств, как вставка тега в произвольную строку запроса, вызывающая срабатывание проверки запроса ASP.NET или манипулирование состоянием представления, также не должны возвращать HTTP 500. Очевидно, что поведение встроенной платформы интерпретировать запрос и, возможно, перебросить его на пользовательскую страницу ошибки, но даже это вернет код ответа 500.
Так что я после некоторых мыслей о том, как подойти к этому. Есть ли способ настроить приложение на уровне .NET или IIS для возврата HTTP 200 при поднятии 500? Или это станет упражнением в кодировании на уровне global.asax в одном из событий приложения? Есть ли другие последствия для рассмотрения?
Кстати, с точки зрения безопасности обоснование заключается в том, что приложения, которые возвращают HTTP 500, могут рассматриваться ботами как «низко висящие плоды», которые случайным образом сканируют уязвимости и вызывают дальнейшую вредоносную активность. Попытки лично меня не убедить, что изменение кодов ответов дает какие-либо реальные преимущества в плане безопасности, но я рад, что воспользовался советом профессионалов.