Web 服务器上禁用的 OPTIONS 标头（.NET Web API 和 Angular）

Posted 2023-03-03

【中文标题】Web 服务器上禁用的 OPTIONS 标头（.NET Web API 和 Angular）

【英文标题】：OPTIONS headers disabled on web server (.NET Web API and Angular)

【发布时间】：2019-04-16 12:39:27

【问题描述】：

我们公司（以及其他一些公司）保持 PCI 合规性。作为我们最近一次安全审计的一部分，我们的基础架构团队和审计员确定应该完全禁用 OPTIONS 标头，因为它构成了安全威胁。

我们在 Angular 6/7 网站上使用 .NET Web API（在多个子域上）。现在禁用 OPTIONS 标头后，来自 Angular 的预检调用被拒绝，我们的应用程序在第一次 API 调用另一个子域时失败（例如，身份验证，这是我们的第一个功能之一，并且在 auth.mycompany.com 上运行我们的应用程序app.mycompany.com)。

我已经阅读了大量内容（如果有人将其标记为重复，如果它导致解决方案，我会很高兴:)）但是，我无法找到任何可行的解决方案。大多数文章都要求将有效的 OPTIONS 调用列入白名单（Why is HTTP Options request insecure 和 https://security.stackexchange.com/questions/138567/why-should-the-options-method-not-be-allowed-on-an-http-server 是两个示例）或在同一子域上设置代理（Preflight CORS requests with Basic Authentication in Angular 2）。

我的问题是，有没有一种方法可以配置 OPTIONS 标头，允许我们通过安全扫描并仍然允许来自 Angular 的 CORS 调用？

提前感谢您的帮助！

【参考方案1】：

我们公司（以及其他一些公司）保持 PCI 合规性。作为我们最近一次安全审计的一部分，我们的基础架构团队和审计员确定应该完全禁用 OPTIONS 标头，因为它构成了安全威胁。

我同意所有域中所有 OPTIONS 的广泛块是有效的安全默认值，但它们应该允许一些 OPTIONS 请求通过正确的服务器，因为它是 HTTP 规范的一部分。

作为标准做法，一些安全团队会阻止所有 POST 请求，您必须请求允许哪些 POST 请求进入网络。

我们无法告诉您这是否是一项好政策。

我的问题是，有没有一种方法可以配置 OPTIONS 标头，允许我们通过安全扫描并仍然允许来自 Angular 的 CORS 调用？

当向另一个域发出请求时，这是由网络浏览器完成的标准安全检查。这是你无法改变的。

这里是您此时的选项列表

请求允许相关 Web 服务器使用 OPTIONS。告诉安全团队，服务器将被修改以产生本质上严格的 OPTIONS 响应并确保安全。 在同一域上托管 Angular Web 应用程序，这样浏览器就不会发出 OPTIONS 请求。 更改所有 API 调用，以便仅向 API 发出不带正文的 GET 请求（空 GET 请求不受 OPTIONS 飞行前请求的影响）。 在与 Angular 应用程序相同的域上创建 API 代理，并让代理向其他域发出所有 API 调用（后端服务器不发出 OPTIONS 请求）。

在实施上述任何一项之前，请先咨询您的安全团队。

【讨论】：

感谢@cgTag，这些选项与我们提出的许多选项相同。我同意你的观点，我们的安全团队应该允许一些 OPTIONS 请求通过。这就是为什么我很想知道业内其他人是如何处理这个问题的，如果有的话。如果我们允许任何 OPTIONS 请求通过，我们的扫描仍然会失败，我们的安全审核也会失败。

@ryanlifferth 安全团队为您制定了一些有关软件开发的架构设计决策。他们对允许使用的现代新技术施加了限制。 OPTIONS 是 CORS 和 RESTful API 的 html5 新标准的一部分。如果公司的政策和文化是按照安全团队的要求去做，那么这就告诉了你可以使用什么样的技术。贵公司的文化可能还没有为现代 Angular 和 RESTful 开发做好准备。在我看来，很多企业都落后于时代10年。

@chTag - 您对设计决策的评论完全正确。非常感谢您的回复，他们证实了我收集的很多信息，并最终帮助我成功解决了问题。我正在写一个描述，以防其他开发人员遇到类似情况。我敢打赌，这个解决方案最终是由浏览器提供商解决的，但现在你的回答帮助我们前进。