Access-Control-Allow-Headers 标头的意义何在答案

【问题标题】：What's the point of the Access-Control-Allow-Headers headerAccess-Control-Allow-Headers 标头的意义何在
【发布时间】：2013-08-02 06:10:22
【问题描述】：

我正在阅读Cross-Origin Resource Sharing 标准，但有一件事对我来说没有意义。

假设我想从域 A 向域 B 发送一个请求，包括一个 Authorization 标头。据我了解，域 B 上的服务器需要通过发送标头 Access-Control-Allow-Headers 来接受这一点。

这有什么意义？我认为同源策略旨在保护来自域 B 的数据不泄露到域 A 上的网站。我不明白 A 发送给 B 的标头有多重要。

【问题讨论】：

这件事在我的脑海里已经有一段时间了。我想知道同样的事情
我想得越多，我就越认为大多数 Web 应用程序可能只是响应 Access-Control-Request-Headers 是可以的。作为一个 webdev/sysadmin，我会告诉你，当你实际尝试某个标头时，它是不允许的；提前告诉你充其量是一个微优化。但作为一个协议设计者，也许我可以想象有人会使用这个功能。如果我能找到任何权威的东西，我会回来添加答案。（关于 CORS 已经写了这么多，为什么这么难找到？？）

标签： html http cross-domain cors

【解决方案1】：

好的，我想我有一个可能的答案：

服务器 B 不希望其他网站上的恶意脚本在登录用户的上下文中向其发送请求。情况：所以服务器 B 说 gmail.com 有 Foo 登录。

服务器 A：malwaresite.com 有一个脚本向 gmail.com 发送一个 xhr 查询邮件列表

由于 Foo 在 gmail.com 上登录，gmail 会识别会话 cookie 并发送列表。

这只有在 gmail.com 允许跨源请求策略时才有可能。否则，用户 Foo 无意中离开的服务器 A 无法从服务器 B(gmail) 获取数据。

这不是为了保护托管站点（发送 xhr 的站点），因为如果站点 A 有意将一些数据发送到服务器 B，则没有理由不这样做。如果有浏览器脚本/恶意软件从服务器 A 的页面发送 xhr，则数据已被泄露。

这就是它保护服务器 B 免受 XSS 攻击的方式。

【讨论】：

这是有道理的。因此，如果 gmail 允许 CORS，他们可以禁止某些标头，并使用这些标头来检测请求是否来自 gmail.com。
虽然这不是一种可靠的方法，但 CORS 几乎否认通过 ajax 进行的会话劫持。如果 session 没有问题，并且攻击者发送 curl 请求，甚至是浏览器请求，gmail 真的无法判断它是 geniune xhr 还是有人欺骗了它
除非我误读了你，否则我不同意。正是 Access-Control-Allow-Origin 机制应该阻止用户的浏览器执行恶意 xhr。你为什么要尝试使用除“origin”之外的任何标题？

【解决方案2】：

请注意，预检请求存在的全部原因是为您在 CORS 之前无法执行的请求提供保护。每个简单的请求（例如不需要预检的请求）都可以使用现有机制完成。例如，没有自定义标头的 GET 请求类似于 JSONP 请求，而没有自定义标头的 POST 请求类似于 JavaScript form.submit()。服务器必须已经准备好从其他域接收这些类型的请求，因为它们可以在没有 CORS 的情况下执行。

CORS 为服务器引入了一系列新的 HTTP 方法和标头。为了验证服务器是否准备好回答这些请求，引入了预检的概念。在将实际请求发送到服务器之前，预检验证是否允许 HTTP 方法/标头的特定组合。

为什么不发送实际请求，而只是阻止客户端接收响应？实际的请求可能有与之相关的副作用（例如，更新或删除数据库条目），并且仅发送请求可能会触发副作用。

发送预检并验证 HTTP 标头可确保服务器不会对 CORS 引入的新请求类型感到惊讶。

【讨论】：