我已经从某些威胁和漏洞人员那里得到了一些有关返回HTTP 500响应代码的网站的反馈。从本质上来说，建议是必须采取一切可能的措施来避免服务器投掷500（即广泛的表单输入验证），这很好。抑制HTTP 500响应代码
但是，该建议还表明，通过将标记插入随机查询字符串中导致ASP.NET请求验证触发或操作视图状态等手段来破坏安全性的尝试也不应该返回HTTP 500.显然，本机框架行为是解释请求并可能抛出一个自定义错误页面，但即使这样也会返回一个500响应代码。
所以我想了解如何解决这个问题。有没有什么办法在.NET级别或IIS级别配置应用程序，以便在引发500时返回HTTP 200？或者这是否成为应用程序事件中的global.asax级别的编码练习？还有其他的后果需要考虑吗？
顺便说一句，从安全侧的理由是，它会返回HTTP 500的应用程序可以通过机器人随机扫描安全漏洞和提示进一步恶意活动被视为“低挂水果”。我个人并不相信修改响应代码会带来任何实际的安全收益，但我很乐意接受专业人士的建议。
要回答你的问题：global.asax是正确的地方，尤其是Application_Error事件处理程序。你应该可以做点像
Response.StatusCode = 200
Response.StatusDescription = "OK"
那里。
PS：不要这样做。 :-)对我来说，这听起来像是另一种违反安全标准的方法。我真的不认为（可能是边缘的）安全增长值得打破正确的HTTP行为（想想谷歌索引你的错误页面等）。
我已经将此标记为正确的答案，因为尽管我同意其他答案是不应该这样做的，但Heinzi是唯一真正回答原始问题的答案。 – 2010-05-24 09:01:11
为什么？没有任何其他信息发回500代码不会给攻击者提供太多信息。
只要你不扔堆栈跟踪，状态转储等，返回给客户端，然后你的罚款。我非常怀疑你想这样做。
严重的是，只需创建一个“500”页面（可选鲸鱼的图片），并返回与您的状态500 - 它提供了什么了。
发送时未成功生成的页面200种状态是完全错误的，可能会导致不好的事情发生 - 比如机器人认为它是一个真正的页面。您不希望在Google上显示“500错误”页面，因为您发送的是200状态。
感谢Mark，正如我所说的，我有同样的担忧，可能会尝试并进行谈判，但在此阶段，我只需要实际的实施方法。 – 2010-02-10 08:41:51
您可以在配置设置自定义错误页 - 你可以重新设置您的自定义错误页
<customErrors mode="On" defaultRedirect="~/DefaultErrorPage.htm" >
<error statusCode="500" redirect="~/CustomError.aspx"/>
</customErrors>
严重警告响应状态...！
确保有没有你的自定义错误页EVER任何错误。通常，你会使用一个html页面，而不是一个aspx页面 - 但是如果你想改变响应头文件，你可能需要使用aspx页面。除了更改标题（即不显示数据库中的任何数据或尝试运行任何逻辑）之外，不要执行其他任何操作，而在自定义错误页面上的错误将导致“重定向次数最大化”错误。
谢谢Sohnee，但您的示例仅基于HTTP状态定义要路由到哪个错误页面。它实际上并没有以任何方式改变代码。 – 2010-02-10 08:40:07
永远不会抛出500错误代码让你更安全？不要听起来对我来说，除非你在调试信息中粘贴错误页面。 – Schwern 2010-02-10 08:06:36
我正在谈论的应用程序与自定义错误，并没有调试或跟踪数据浮出水面。正如我上面所说的，这个职位并不是说它使应用程序更安全，而是使其不太可能成为入侵企图的潜在候选人。 – 2010-02-10 19:44:23
除了错误页面（url模式，表单字段名称，HTML样式，自定义HTTP标头...），还有很多其他提示您使用的应用程序，所以我不知道有多少真正的安全值抑制应用程序的自定义错误页面是。即使你确实隐藏了你正在使用的应用程序，但它只是混淆。当然，不应该采取“一切可能的措施”，当然也不会对客户说错了。 MarkR有最好的答案，创建一个通用的，静态的，全站500错误页面，比如Twitter的失败鲸鱼或Github的愤怒的独角兽。 – Schwern 2010-02-10 23:12:10