现在，由于这个限制，许多CORS被实现，使得网站能够做出跨源请求。但是根据我对CORS的理解，违反了“同源政策”SOP的安全目标
CORS只是为了提供对要求服务的请求服务器的额外控制。也许它可以避免垃圾邮件发送者。
To initiate a cross-origin request,a browser sends the request with
an Origin HTTP header. The value of this header is the site that
served the page. For example,suppose a page on
07001 attempts to access a user’s data
in online-personal-calendar.com. If the user’s browser implements
CORS,the following request header would be sent:Origin: 07001
If online-personal-calendar.com allows the request,it sends an
Access-Control-Allow-Origin header in its response. The value of the
header indicates what origin sites are allowed. For example,a
response to the prevIoUs request would contain the following:Access-Control-Allow-Origin: 07001
If the server does not allow the cross-origin request,the browser
will deliver an error to example-social-network.com page instead of
the online-personal-calendar.com response.To allow access to all pages,a server can send the following response
header:Access-Control-Allow-Origin: *
However,this might not be appropriate for situations in which
security is a concern.
我在这里失踪了什么是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
