Ada*_*son 9 security firewall header http
作为Web开发人员,我越来越多地调试问题,发现我们的IT部门正在使用我们的防火墙来过滤HTTP响应标头.
他们正在使用已知标头的白名单,因此某些较新的技术(CORS,websockets等)会被自动剥离,直到我调试问题并请求列入白名单.
受影响的响应是我们正在使用的第三方服务 - 因此,如果我们有一个使用disqus的内部站点,则无法加载注释,因为disqus的响应正在删除它的标头.我们服务的资源不会受到影响,因为它只是进入办公室的流量.
是否有正当理由阻止某些标题？显然存在诸如中间人,重定向到钓鱼网站等问题,但这些需要的不仅仅是错误的标题才能成功.
维护允许的HTTP响应标头的白名单有哪些安全原因？
指纹识别可能是剥离响应标头的主要原因：
https://www.owasp.org/index.php/Fingerprint_Web_Server_%28OTG-INFO-002%29
这取决于您正在运行的堆栈，并且大多数时候，响应标头中包含的信息在每个服务器中都是可配置的，但它需要单独篡改每个服务应用程序（并且可能存在软件私有的情况）并且不提供设置 HTTP 标头的选项）。
让我们看一个简单的例子：
在我们的示例数据中心中，我们正在运行一组用于不同目的的服务器，并且我们已经正确配置了它们，以便它们在标头上不会返回不必要的元数据。
然而，其中一台服务器上安装了一个用于管理打印作业的新（假想的）闭源应用程序，并且它提供了一个我们出于某种原因想要使用的 Web 界面。如果此应用程序返回一个附加标头，例如（比方说）“x-printman-version”（它可能想要这样做，以确保与使用其 API 的客户端兼容），它将有效地公开其版本。
而且，如果此打印作业管理器存在某些版本的已知漏洞，攻击者只需查询它即可知道此特定安装是否存在漏洞。
这可能看起来不那么重要，但它打开了一个自动/随机攻击的窗口，扫描感兴趣的端口，并等待正确的标头出现（“指纹”），以便发动攻击并确保成功。
因此，在组织中剥离大部分（为我们想要保留的内容设置策略和规则）额外的 HTTP 标头可能听起来很明智。
明确这一点后，从传出连接响应中剥离标头就显得有些过分了。确实，它们可以构成一个向量，但由于它是传出连接，这意味着我们“信任”端点。控制受信任端点的攻击者会使用元数据而不是有效负载，并没有直接的原因。
我希望这有帮助！