我从一些与返回 HTTP 500 响应代码的网站相关的威胁和漏洞人员那里得到了一些反馈。基本上建议是必须采取所有可能的措施来避免服务器抛出 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"
Run Code Online (Sandbox Code Playgroud)
那里。
PS:不要这样做。:-) 对我来说,这听起来像是另一种违反标准的安全方法。我真的不认为(可能是微不足道的)安全性增加值得破坏正确的 HTTP 行为(想想谷歌索引你的错误页面等)。
| 归档时间: |
|
| 查看次数: |
2875 次 |
| 最近记录: |