引入飞行前CORS要求的动机是什么?

引入飞行前请求的动机是什么?

引入了Preflight请求，以便浏览器在发送特定请求之前可以确定它正在处理一个支持cors的服务器。这些请求被定义为既具有潜在危险(状态改变)又具有新请求(由于同源政策，在CORS之前是不可能的)。使用飞行前请求意味着服务器必须选择(通过正确地响应飞行前请求)接受CORS使之成为可能的新的、具有潜在危险的请求类型。

这就是原始规范的这一部分的含义:“为了保护资源不受在此规范存在之前不能来自某些用户代理的跨起源请求的影响，发出预飞行请求以确保资源知道此规范。”

你能给我举个例子吗?

让我们假设一个浏览器用户登录到他们的银行网站A.com。当他们导航到恶意的B.com时，该页面包含一些试图向A.com/account发送DELETE请求的Javascript。由于用户登录到A.com，如果发送该请求，将包括识别用户的cookie。

在CORS之前，浏览器的同源策略会阻止它发送此请求。但由于CORS的目的是使这种跨起源通信成为可能，这已经不合适了。

浏览器可以简单地发送DELETE并让服务器决定如何处理它。但是如果。com不知道CORS协议怎么办?它可能会继续执行危险的DELETE。由于浏览器的同源策略(Same Origin policy)，它可能认为它永远不会收到这样的请求，因此它可能从来没有对这样的攻击进行过加固。

为了保护这些不支持cors的服务器，该协议要求浏览器首先发送一个飞行前请求。这种新的请求只有支持cors的服务器才能正确响应，从而允许浏览器知道发送实际的DELETE是否安全。

为什么浏览器这么麻烦，攻击者就不能从他们自己的电脑发送一个DELETE请求吗?

当然，但是这样的请求不包括用户的cookie。这种设计用来防止的攻击依赖于这样一个事实:浏览器将在请求的同时为其他域发送cookie(特别是用户的身份验证信息)。

这听起来像是跨站请求伪造，即站点B.com上的表单可以用用户的cookie提交给A.com，并造成破坏。

这是正确的。另一种说法是，创建预飞行请求是为了不增加非cors感知服务器的CSRF攻击面。

但是POST被列为一种不需要预先操作的方法。它可以改变状态和删除数据，就像delete !

这是真的!CORS不能保护您的站点免受CSRF攻击。然而，如果没有CORS，您也无法免受CSRF攻击。飞行前请求的目的只是限制你的CSRF暴露在cors之前已经存在的世界。

叹息。好的，我勉强接受飞行前的要求。但是为什么我们必须对服务器上的每个资源(URL)都这样做呢?服务器要么处理CORS，要么不处理。

你确定吗?多个服务器处理单个域的请求并不罕见。例如，对A.com/url1的请求可能由一种服务器处理，而对A.com/url2的请求由另一种服务器处理。处理单个资源的服务器通常不能对该域中的所有资源提供安全保证。

好吧。让我们妥协。让我们创建一个新的CORS头，它允许服务器确切地声明它可以代表哪些资源，这样就可以避免对这些url的额外预飞行请求。

好主意!事实上，头文件Access-Control-Policy-Path正是为此目的而提出的。但最终，它被排除在规范之外，这显然是因为一些服务器错误地实现了URI规范，使得对浏览器来说似乎安全的路径的请求在损坏的服务器上实际上并不安全。

这是一个谨慎的决定，优先考虑安全性而不是性能，允许浏览器立即实现CORS规范，而不会使现有服务器处于危险之中?或者，仅仅为了在特定时间适应特定服务器上的漏洞，就注定要浪费互联网的带宽和加倍的延迟，这是短视的做法吗?

意见不同。

那么，至少浏览器会为单个URL缓存preflight ?

是的。虽然可能不会持续太久。在WebKit浏览器中，最大的预缓存时间目前是10分钟。

叹息。好吧，如果我知道我的服务器是cors感知的，因此不需要飞行前请求提供的保护，有什么方法可以避免它们吗?

您唯一的选择是确保您的请求使用cors安全的方法和头。这可能意味着省略您本来应该包含的自定义头文件(如X-Requested-With)，更改Content-Type等等。

无论您做什么，都必须确保有适当的CSRF保护，因为CORS不会阻止所有不安全的请求。正如最初的规范所说:“对于那些简单的请求有意义而不是检索的资源，必须保护自己不受跨站点请求伪造的侵害”。

2017-01-17 01:36:41

预先飞行的请求不是关于性能的吗?通过预飞行请求，客户端可以在发送大量数据之前快速知道该操作是否允许，例如，在JSON中使用PUT方法。或者在通过网络传输身份验证头中的敏感数据之前。

事实上，除了自定义头之外，默认情况下不允许使用PUT、DELETE和其他方法(它们需要“Access-Control-Request-Methods”和“Access-Control-Request-Headers”的显式权限)，这听起来就像一个双重检查，因为这些操作可能会对用户数据产生更多影响，而不是GET请求。听起来是这样的:

“我看到你允许来自http://foo.example的跨站请求，但你确定你会允许删除请求吗?你考虑过这些请求可能对用户数据造成的影响吗?”

我不理解所引用的预飞行请求和旧服务器的好处之间的相关性。在CORS之前实现的Web服务，或者没有CORS意识的Web服务，将永远不会接收任何跨站点请求，因为首先它们的响应不会有“Access-Control-Allow-Origin”报头。

2015-05-02 20:02:06

下面是另一种看待它的方式，使用代码:

<!-- hypothetical exploit on evil.com -->
<!-- Targeting banking-website.example.com, which authenticates with a cookie -->
<script>
jQuery.ajax({
  method: "POST",
  url: "https://banking-website.example.com",
  data: JSON.stringify({
    sendMoneyTo: "Dr Evil",
    amount: 1000000
  }),
  contentType: "application/json",
  dataType: "json"
});
</script>

在cors之前，上述利用尝试将会失败，因为它违反了同源策略。以这种方式设计的API不需要XSRF保护，因为它受到浏览器本地安全模型的保护。cors之前的浏览器不可能生成跨源JSON POST。

现在CORS出现了——如果不需要通过飞行前选择加入CORS，突然之间这个网站就会有一个巨大的漏洞，这不是他们自己的过错。

为了解释为什么一些请求被允许跳过预飞行，这是在规范中回答的:

简单的跨源请求被定义为与这些请求一致哪些可能是由当前部署的用户代理生成的遵守这个规范。

为了解决这个问题，GET没有预先运行，因为它是7.1.5中定义的“简单方法”。(标题也必须“简单”，以避免预飞行)。这样做的理由是，“简单的”跨源GET请求已经可以通过例如<script src="">来执行(这是JSONP的工作方式)。由于任何具有src属性的元素都可以触发跨源GET，没有预先飞行，因此在“简单”xhr上要求预先战斗将没有安全好处。

2016-05-05 01:01:58

我觉得其他的答案并没有把重点放在战前提高安全性的原因上。

场景:

1) With pre-flight. An attacker forges a request from site dummy-forums.com while the user is authenticated to safe-bank.com If the Server does not check for the origin, and somehow has a flaw, the browser will issue a pre-flight request, OPTION method. The server knows none of that CORS that the browser is expecting as a response so the browser will not proceed (no harm whatsoever) 2) Without pre-flight. An attacker forges the request under the same scenario as above, the browser will issue the POST or PUT request right away, the server accepts it and might process it, this will potentially cause some harm.

如果攻击者直接从某个随机主机发送请求，那么很有可能是没有经过身份验证的请求。这是伪造的请求，但不是xsrf请求。服务器会检查凭证并失败。 CORS并不试图阻止拥有发出请求的凭据的攻击者，尽管白名单可以帮助减少这种攻击向量。

预飞行机制增加了客户端和服务器之间的安全性和一致性。我不知道这是否值得为每个请求额外握手，因为缓存在那里是可以使用的，但这就是它的工作原理。

2015-09-14 15:54:47