我正在阅读跨域资源共享标准，但有一件事对我来说没有意义。
假设我想从域 A 向域 B 发送一个请求，包括一个 Authorization 标头。据我了解，域 B 上的服务器需要通过发送标头 Access-Control-Allow-Headers 来接受这一点。
这有什么意义？我认为同源策略旨在保护来自域 B 的数据不泄露到域 A 上的网站。我不明白 A 发送给 B 的标头有多重要。
问问题
1079 次
2 回答
3
好的，我想我有一个可能的答案：
服务器 B 不希望其他网站上的恶意脚本在登录用户的上下文中向其发送请求。情况：所以服务器 B 说 gmail.com 有 Foo 登录。
服务器 A：malwaresite.com 有一个脚本，它向 gmail.com 发送一个 xhr 查询邮件列表
由于 Foo 登录 int gmail.com，gmail 识别会话 cookie 并发送列表。
这只有在 gmail.com 允许跨源请求策略时才有可能。否则，用户 Foo 无意中离开的服务器 A 无法从服务器 B(gmail) 获取数据。
这不是为了保护托管站点（发送 xhr 的站点），因为如果站点 A 故意想要将一些数据发送到服务器 B，则没有理由不这样做。如果有浏览器脚本/恶意软件正在从服务器 A 的页面发送 xhr，则数据已经受到威胁。
这就是它保护服务器 B 免受 XSS 攻击的方式。
于 2013-08-01T11:07:56.270 回答
1
请注意，预检请求存在的全部原因是为您在 CORS 之前无法执行的请求提供保护。每个简单的请求（例如不需要预检的请求）都可以使用现有机制完成。例如，没有自定义标头的 GET 请求类似于 JSONP 请求，而没有自定义标头的 POST 请求类似于 JavaScript form.submit()。服务器必须已经准备好从其他域接收这些类型的请求，因为它们可以在没有 CORS 的情况下执行。
CORS 为服务器引入了一系列新的 HTTP 方法和标头。为了验证服务器是否准备好回答这些请求，引入了预检的概念。在将实际请求发送到服务器之前，预检验证是否允许 HTTP 方法/标头的特定组合。
为什么不发送实际请求，而只是阻止客户端接收响应？实际的请求可能具有与之相关的副作用（例如，更新或删除数据库条目），并且仅发送请求可能会触发副作用。
发送预检并验证 HTTP 标头可确保服务器不会对 CORS 引入的新型请求感到惊讶。
于 2013-08-01T15:22:34.017 回答