似乎CORS的飞行前检查没有任何意义.开个玩笑吗? [英] It seems the pre-flight for CORS doesn't make sense. Is it a joke?

问题描述

根据来自此处的示例:

如果请求使用GET，HEAD或POST以外的方法.另外，如果POST 用于发送Content-Type以外的Content-Type的请求数据 application/x-www-form-urlencoded，multipart/form-data或text/plain， 例如如果POST请求使用以下命令向服务器发送XML负载 application/xml或text/xml，然后该请求将被预检.

If a request uses methods other than GET, HEAD or POST. Also, if POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g. if the POST request sends an XML payload to the server using application/xml or text/xml, then the request is preflighted.

因此，在下面的示例中，由于XML Content-Type和自定义标头X-PINGOTHER，因此执行了预检:

So in the following example, the pre-flight is carried out because of the XML Content-Type and the custom header X-PINGOTHER:

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong'); //<====
      invocation.setRequestHeader('Content-Type', 'application/xml'); //<====
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}

但是在所谓的飞行前OPTIONS请求(如下)中，仅将HTTP方法和自定义标头通知服务器. 没有人告诉服务器有关XML Content-Type 的信息.

But in the so-called pre-flight OPTIONS request (below), the server is only notified of the HTTP method and custom header. No one told the server about the XML Content-Type.

从逻辑上讲，只要发送了预检请求，它就会暗含 Content-Type 而不是不需要预检的3种形式.但是，还有许多其他可能性. 最重要的是，服务器应该能够知道为什么发送预检请求.

Logically, as long as the preflight request is sent, it implies the Content-Type is not in the 3 forms which need no preflight. But there can be numerous other possibilities. The bottom line is, server should be able to know why the preflight request is sent.

那么服务器如何合理地决定是否允许缺少部分内容(内容类型)的请求?

推荐答案

CORS几乎总是安全的.引用自获取标准

CORS is almost always safe. Quoting from the Fetch Standard,

对于那些通过IP认证或数据保护来保护数据的资源 防火墙(不幸的是仍然比较普遍)，使用CORS 协议不安全. (这就是为什么CORS协议必须 被发明.)

For resources where data is protected through IP authentication or a firewall (unfortunately relatively common still), using the CORS protocol is unsafe. (This is the reason why the CORS protocol had to be invented.)

但是，否则使用以下标头是安全的:

However, otherwise using the following header is safe:

访问控制允许来源:*

Access-Control-Allow-Origin: *

即使资源基于Cookie公开了其他信息， 使用上述标头的HTTP身份验证将不会显示它.它 将与XMLHttpRequest之类的API共享资源，就像它一样 已与curl和wget共享.

Even if a resource exposes additional information based on cookie or HTTP authentication, using the above header will not reveal it. It will share the resource with APIs such as XMLHttpRequest, much like it is already shared with curl and wget.

因此，如果无法从随机访问资源 使用curl和wget连接到Web的设备 标头不包括在内.如果可以访问，则为 这样做非常好.

Thus in other words, if a resource cannot be accessed from a random device connected to the web using curl and wget the aforementioned header is not to be included. If it can be accessed however, it is perfectly fine to do so.

因此，服务器不需要了解有关请求内容类型的任何信息即可知道如何响应OPTIONS请求.服务器只需要知道:是否仅通过基于IP的身份验证或在某些防火墙或Intranet之后才被询问有关URL的URL?如果是，则应拒绝OPTIONS请求.如果不是，即如果使用curl，wget，telnet或您喜欢的HTTP库之类的工具通过公共互联网访问资源，则该资源应允许OPTIONS请求.这样做只会为浏览器提供与其他工具相同的访问权限.

Thus, a server does not need to know anything about the content type of the request to know how to respond to the OPTIONS request. The server just needs to know: is the URL being asked about only accessible via IP-based authentication, or behind some firewall or intranet? If it is, then it should deny the OPTIONS request. If it is not, i.e. if the resource is accessible via the public internet using tools like curl, wget, telnet, or your favorite HTTP library, then it should allow the OPTIONS request. Doing so will just give browsers the same access as those other tools.

然后，当后续的POST请求进入时，服务器可以做出进一步的决定.例如，服务器可能希望拒绝使用错误的Content-Type的POST.但是它总是想这样做.不想只拒绝来自CORS的浏览器的OPTIONS请求；相反，它应该拒绝任何来源的POST请求.

The server can then make further decisions when the subsequent POST request comes in. For example, maybe the server wants to reject POSTs with the wrong Content-Type. But it would always want to do this. It wouldn't want to only reject the OPTIONS request from CORS-respecting browsers; instead it should reject the POST request, from any source.

(浏览器之所以如此特殊，是因为以下原因.请考虑一个内部网，该内部网遵循不良的安全做法，并且其IP地址在一定范围内的任何人(例如，使用公司计算机的任何人)都可以读取.通常，这是没有问题的:使用curl的公司内部人员可以访问数据，而使用curl的公司外部人员不能访问数据.但是，请考虑使用公司内部的人员浏览某些恶意网站， https://evil.com/.如果evil.com使用XHR API访问 http ://intranet/secret-data ，然后请求将来自特权IP地址，因为它是特权用户计算机上执行请求的浏览器.泄漏时，发明了CORS协议，因此与其对 http://intranet/secret-data http://intranet/secret-data ，浏览器首先执行一个O PTIONS请求，对于该请求，整个 http://intranet 可能只会说不，您不能访问它"，然后POST永远不会发生.)

(The reason why browsers are special is the following. Consider an intranet that follows bad security practices and is readable by anyone with their IP address in a certain range, i.e. anyone using a company computer. Normally, that is no problem: people inside the company who use curl can access the data, and people outside it who use curl cannot. However, consider someone inside the company that browses to some malicious website, https://evil.com/. If evil.com uses the XHR API to access http://intranet/secret-data, then the request will come from a privileged IP address, since it's the browser on the privileged user's computer doing the request. To prevent these kind of security leaks, the CORS protocol was invented, so that instead of doing a direct POST to http://intranet/secret-data, the browser first does an OPTIONS request, for which the whole of http://intranet will probably just say "no you can't access this", and then the POST never happens.)

这篇关于似乎CORS的飞行前检查没有任何意义.开个玩笑吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！