了解AJAX CORS和安全考虑事项

Question

我想了解为什么CORS正在以它的方式工作。

当我从this post，当从www.a.com页使得AJAX请求www.b.com了解到，那么它的www.b.com是决定是否请求应当被允许或不。

但是在这样的模型中，客户端的确切担保是什么？ 例如，如果黑客成功将XSS脚本注入到我的页面，那么它向他的域发出一个AJAX请求来存储用户数据。所以黑客的域名肯定会允许这样的请求。

我认为www.a.com应该决定哪些域允许请求。所以在理论上在一个标题访问控制，允许来源我想把整个允许AJAX CORS请求的域列表。

有人可以解释当前的CORS实现处理什么安全问题吗？

Answer 1

正如我这个职位，当从www.a.com页面使得AJAX请求www.b.com教训，那么它是决定是否请求应当被允许或不www.b.com。

不完全。该请求未被阻止。

默认情况下，在www.a.com上运行的JavaScript禁止访问www.b.com的响应。

CORS允许www.b.com允许来自www.a.com的JavaScript访问响应。

但是在这样的模型中客户端的确切安全性是什么？

它停止的www.a.com笔者从使用谁访问了网站和已通过验证的www.b.com（因此访问非公共数据）的用户的浏览器www.b.com读取数据。

例如，Alice登录到Google。 Alice访问malicious.example，它使用XMLHttpRequest访问gmail.com中的数据。 Alice有一个GMail帐户，因此该回复列出了收件箱中最近一次发送的电子邮件。相同的原产地政策阻止malicious.example读取它。

例如，黑客成功让XSS脚本注入到我的页面，然后它向他的域发出AJAX请求来存储用户数据。所以黑客域名肯定会允许这样的请求。

正确。 XSS是一个不同的安全问题，需要在源代码中解决（即在www.a.com而不是在浏览器中）。

Answer 2

除了@Quentin's excellent answer之外，还有另一种技术被称为Content Security Policy，它描述了你在做什么。

我以为www.a.com应该决定哪些域允许请求。所以理论上在一个头部访问控制 - 允许 - 来源我想把整个允许AJAX CORS请求的域列表。

随着CSP，你可以从你的域（www.a.com在你的例子）设置一个头，以限制AJAX请求：

连接-SRC限制起源，你可以连接（通过XHR，WebSockets的和EventSource）。

所以使用这个，你可以在此Content-Security-Policy HTTP头添加到您的HTML响应：

Content-Security-Policy: connect-src 'self' 

这将限制AJAX请求www.a.com如果标题是从www.a.com响应：

'self'与当前的原点匹配，但不是其子域名

See here支持的浏览器。