ajax – 同源策略和CORS(跨原始资源共享)

同源政策

它是什么？

同源策略是浏览器之间的标准化安全措施。 “起源”主要是指“领域”。它可以防止不同的来源相互交互，以防止诸如“跨站点请求伪造”等攻击。

CSRF攻击如何工作？

浏览器允许网站以客户端计算机的形式存储信息，以…的形式。这些饼干有一些附加信息。像cookie的名称一样，它创建的时间是什么时候到期，谁设置了cookie等。一个cookie看起来像这样：

饼干：cookiename =巧克力域= .bakery.com; Path = / [//; otherDdata]

所以这是一个巧克力饼干。应该从http://bakery.com及其所有子域可访问。

此Cookie可能包含一些敏感数据。在这种情况下，该数据是…巧克力。高度敏感，你可以看到。

所以浏览器存储这个cookie。并且每当用户向可访问此cookie的域发出请求时，该cookie将被发送到该域的服务器。快乐的服务器

这是一件好事。超酷的方式可以让服务器在客户端上存储和检索信息。
但问题是这允许http://malicious-site.com将这些cookie发送到http://bakery.com，没有用户知道！例如，考虑以下情况：

# malicious-site.com/attackpage

var xhr = new XMLHttpRequest();
xhr.open('GET','http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();

如果您访问恶意网站，并且上述代码执行，并且同源策略不存在，恶意用户将代表您下订单，并在他的位置获得订单，您可能不会喜欢事情。

这是因为您的浏览器将您的巧克力饼干发送到http://bakery.com，这使得http://bakery.com认为您正在为新订单提出请求。但你不是

简单来说，这是一个CSRF攻击。 “交叉”“网站”提出了“请求”，请求是“伪造的”。 “跨站点请求伪造”。由于同源政策，这不行。

同源政策如何解决这个问题？

它会阻止恶意网站向其他域发出请求。简单。

换句话说，浏览器不允许任何网站向任何其他站点发出请求。这将阻止不同的起源通过诸如AJAX之类的请求彼此交互。

但是，从图像，脚本，样式表，iframe，表单提交等其他主机的资源加载不受此限制。使用CSRF Tokens，我们需要另一面墙来保护我们的面包店免受恶意网站的侵害。

CSRF令牌

如上所述，恶意网站仍然可以做这样的事情，而不违反同源政策：

<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>

浏览器将尝试从该URL加载映像，导致向该URL发送所有cookie的GET请求。为了防止这种情况发生，我们需要一些服务器端保护。

基本上，我们在用户会话中附加一个合适熵的随机唯一令牌，将其存储在服务器上，并将其发送给客户端。当提交表单时，客户端会将该令牌与请求一起发送，并且服务器会验证该令牌是否有效。

现在我们已经做到了这一点，恶意网站再次发送请求，一直都会失败，因为恶意网站没有可行的方式知道用户会话的令牌。

CORS

当需要时，当需要跨站点请求时，可以规避策略。这被称为CORS。跨原产资源共享。

这通过让“域”告诉浏览器进行冷却，并允许这样的请求。这个“告诉”的事情可以通过传递头来完成。就像是：

Access-Control-Allow-Origin：//逗号分隔允许的起始列表，或只是*
因此，如果http://bakery.com将此标头传递到浏览器，并且创建到http://bakery.com的请求的页面存在于原始列表中，那么浏览器将让请求与Cookie一起。

有定义原则的规则1。例如，同一域的不同端口不一样。因此，如果端口不同，浏览器可能会拒绝此请求。和往常一样，我们亲爱的Internet Explorer是这样的例外。 IE以相同的方式对待所有端口。这是非标准的，没有其他浏览器这样做。不要依赖这个。

JSONP

当使用CORS不是一个选项时，使用填充的JSON只是一种绕过同源策略的方法。这是有风险和不好的做法。避免使用这个。

这个技术涉及的是向其他服务器发出请求，如下所示：

< script src =“http://badbakery.com/jsonpurl?callback=cake”>< / script>

由于同源策略不会阻止此请求，因此该请求的响应将被加载到页面中。

这个网址最有可能用JSON内容来回应。但是，只有在该页面上包含JSON内容才会有所帮助。这将导致错误。所以http://badbakery.com接受一个回调参数，并修改JSON数据，将其发送到传递给回调参数的任何内容中。

所以，而不是返回，

{user：“vuln”，acc：“B4D455”}

这是无效的JavaScript抛出一个错误，它会返回，

蛋糕({user：“vuln”，acc：“B4D455”});

这是有效的JavaScript，它将被执行，并且可能根据蛋糕功能存储在某个地方，以便页面上的其余JavaScript可以使用数据。

API主要用于将数据发送到其他域。再次，这是一个不好的做法，可能是危险的，应该严格避免。

为什么JSONP不好

首先，这是非常有限的。如果请求失败，则无法处理任何错误(至少不是一个正确的方式)。您无法重试请求等

它还要求您在全球范围内拥有蛋糕功能，这不是很好。如果需要使用不同的回调执行多个JSONP请求，厨师可以节省您。这是通过各种图书馆的临时功能来解决的，但仍然是一个黑客的方式。

最后，您在DOM中插入随机JavaScript代码。如果您不是100％确定远程服务将返回安全的蛋糕，您不能依赖此。

参考

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin

https://www.w3.org/Security/wiki/Same_Origin_Policy#Details

其他值得读的

070011

070012 (sorry :p)

070013

070014