作为安全测试人员，我需要报告并证明第三方应用程序中的安全错误配置对我们来说是一种风险。
以下是场景：
1.) 客户使用第 3 方应用程序向我们提交申请。我们从第 3 方应用程序接收数据并进一步处理它们。
2.) 在该特定应用程序中，单击超链接后，将显示错误页面，其中包含以下信息：
a) Source file path (however it is forbidden when tried to access)
b) .Net framework version which is vulnerable ASP.Net Forms Authentication Bypass
c) IIS server version (7.5) which has exploits as per my knowledge.
这种错误配置对我们有什么风险。如何证明它的合理性？
注意：此错误页面仅在用户登录后出现。这是一个面向公众的应用程序。
源文件路径不一定是问题。然而，这是一种不好的做法，并且会泄露可能对利用其他问题有用的信息。
据我所知，IIS 服务器版本（7.5）具有漏洞。
IIS 7.5 在 2020 年之前仍处于扩展支持状态。这意味着它应该会收到安全更新 - 所以这不一定是问题。您需要向第 3 方请求补丁历史记录。
.Net 框架版本易受攻击 ASP.Net Forms Authentication Bypass
这又被修补了。版本号本身没有任何意义。
这种错误配置对我们有什么风险。如何证明它的合理性？
您的客户向您提交的具体内容是什么？如果有应用程序可执行文件，这些是公开分发的吗？还是它们是服务器端应用程序？他们签名了吗？
我能看到的最大安全风险是，如果有人在提交给自己之前修补了应用程序中的缺陷。因此，客户将有一个您无法让他们意识到的漏洞。
作为安全最佳实践，始终建议不要将有关系统的任何信息泄露给公共/合法用户。
这可能会导致安全漏洞，因为黑客可能会使用此信息来查找系统/应用程序中的漏洞。
例如，IIS 7.5 存在大量漏洞，请参考https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-3436/version_id-92758/Microsoft-IIS-7.5.html。
ASP.NET 有几个漏洞，请参考https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-3091/Microsoft-Asp.net.html。
因此，始终建议保护系统的后端信息。