我们的 Web 应用程序有一个错误页面,其中显示了发生错误的页面的绝对 URL 路径和查询、错误的日期/时间以及异常消息。(我们不显示堆栈跟踪。这是一个明显的漏洞。)
在错误页面中显示异常消息是否存在漏洞?
为了获得最大的安全性,我们应该在错误页面中显示什么?我们不应该展示什么?
编辑:我的直觉是它是一个漏洞,但我想听听专家的意见。
我们的 Web 应用程序有一个错误页面,其中显示了发生错误的页面的绝对 URL 路径和查询、错误的日期/时间以及异常消息。(我们不显示堆栈跟踪。这是一个明显的漏洞。)
在错误页面中显示异常消息是否存在漏洞?
为了获得最大的安全性,我们应该在错误页面中显示什么?我们不应该展示什么?
编辑:我的直觉是它是一个漏洞,但我想听听专家的意见。
在某些情况下,错误消息会导致漏洞。在密码学领域,填充预言攻击可以通过发送更改的加密消息来恢复密钥,并使用区分两种失败的“预言”(“填充错误”与“存在有效填充,但结果数据是乱码”)。详细的错误消息很有可能成为这样的预言机。在更一般的概念视图中,攻击者将试图通过刺激系统并观察发生的情况来发现弱点,更多的数据只能帮助他们。在这方面,异常消息在质量上与堆栈跟踪没有区别;所以如果堆栈跟踪是一个“明显的”漏洞,那么异常消息也必须是。
除了提供攻击面枚举外,路径披露/路径泄漏还可用于对应用程序及其底层服务器进行指纹识别。几乎每个使用动态页面的 Web 应用程序都会泄露本地 Web 服务器路径,有时其中包含用户名和明显易受攻击的目录。
它们也可以在文件包含或脚本包含攻击期间被利用。必须特别注意 PHP/CTP、ASP/ASPX 和 JSP/JSPX 文件,以防止路径泄露消息容易变成文件包含攻击,例如可以读取本地文件。
我不一定将其称为漏洞本身。仅此例外可能不足以破坏服务器的安全性。
但它是一个弱点,可能会泄露有助于攻击者的信息,或者让他们踏上大门。例如,它可能会显示有关代码或软件版本的信息。它可能使攻击者更容易尝试攻击并了解如何调整它们以使其工作。
此外,有时攻击者能够将多个弱点组合在一起并结合它们来构建完整的漏洞利用。没有任何一个弱点本身就是漏洞,也就是说,没有任何一个弱点本身就可以让攻击者破坏您系统的安全性。但是,当攻击者以一种巧妙的方式将它们结合起来时,有时它们会提供足够的垫脚石来允许全面的安全漏洞。
由于这些原因,我倾向于对这些“弱点”保持谨慎。如果可以的话,尽量避免它们似乎更安全。