为什么对于标准内容类型的POST请求，CORS中没有预检 [英] Why is there no preflight in CORS for POST requests with standard content-type

问题描述

我对CORS POST请求的安全性有些困惑.我知道在线上没有有关此主题的信息，但是我找不到我的问题的明确答案.

I'm a bit confused about the security aspects of CORS POST requests. I know there is a lost of information about this topic online, but I couldn't find a definite answer to my questions.

如果我理解正确，那么同源策略的目标是防止CSRF攻击，而CORS的目标是在(且仅当)服务器同意与其他主机上托管的应用程序共享其数据时启用资源共享.网站(来源).

If I understood it correctly, the goal of the same-origin policy is to prevent CSRF attacks and the goal of CORS is to enable resource sharing if (and only if) the server agrees to share its data with applications hosted on other sites (origins).

HTTP指定POST请求不是``安全的''，即它们可能会更改服务器的状态，例如通过添加新评论.当使用HTTP方法POST发起CORS请求时，浏览器仅在请求的内容类型为非标准(或存在非标准的HTTP标头)时才执行安全"预检请求.因此带有标准内容类型和标准标头的POST请求将被执行，并且可能会对服务器产生负面影响(尽管请求脚本可能无法访问该响应.)

HTTP specifies that POST requests are not 'safe', i.e. they might change the state of the server, e.g. by adding a new comment. When initiating a CORS request with the HTTP method POST, the browser only performs a 'safe' preflight request if the content-type of the request is non-standard (or if there are non-standard http headers). So POST requests with standard content-type and standard headers are executed and might have negative side effects on the server (although the response might not be accessible to the requesting script.)

有一种向每种形式添加随机令牌的技术，然后服务器要求它成为每个非安全"请求的一部分.如果脚本尝试伪造请求，则可以选择

There is this technique of adding a random token to every form, which the server then requires to be part of every non-'safe' request. If a script tries to forge a request, it either

1. 没有随机令牌，服务器拒绝了该请求，或者
2. 它尝试访问定义了随机令牌的表单.具有随机令牌的此响应应具有适当的头字段，以使浏览器不会授予邪恶脚本对此响应的访问权限.同样在这种情况下，尝试也会失败.

我的结论是，针对具有标准内容类型和标头的伪造POST请求的唯一保护措施是上述技术(或类似技术).对于任何其他非安全"请求(例如PUT或DELETE或具有json-content的POST)，由于CORS执行安全"选项请求，因此不必使用该技术.

My conclusion is that the only protection against forged POST requests with standard content-type and headers is the technique described above (or a similar one). For any other non-'safe' request such as PUT or DELETE, or a POST with json-content, it is not necesssay to use the technique because CORS performs a 'safe' OPTIONS request.

为什么CORS的作者将这些POST豁免排除在飞行前请求之外，因此必须采用上述技术?

Why did the authors of CORS exclude these POST exempt from preflight requests and therefore made it necessary to employ the technique described above?

推荐答案

请参见

See CORS - What is the motivation behind introducing preflight requests? and other answers there.

CORS不需要浏览器对application/x-www-form-urlencoded，multipart/form-data或text/plain内容类型进行预检的原因是，如果这样做，这会使CORS比浏览器已经允许的限制更多(而且，CORS的意图不是对没有CORS的情况施加新的限制).

The reason CORS doesn’t require browsers to do a preflight for application/x-www-form-urlencoded, multipart/form-data, or text/plain content types is that if it did, that’d make CORS more restrictive than what browsers have already always allowed (and it’s not the intent of CORS to put new restrictions on what was already possible without CORS).

也就是说，对于CORS，您以前可以执行跨域的POST请求不会被预先处理-因为在CORS存在之前浏览器已经允许它们，并且服务器知道它们.因此，CORS不会改变那些旧"类型的请求.

That is, with CORS, POST requests that you could do previously cross-origin are not preflighted—because browsers already allowed them before CORS existed, and servers knew about them. So CORS changes nothing about those "old" types of requests.

但是在使用CORS之前，浏览器根本不允许您执行跨域application/json POST，因此服务器可以假定它们不会接收到它们.因此，对于这些类型的新"请求而不是旧"请求，都需要进行CORS预检-提醒服务器这是另一种新"请求，他们必须明确选择-来支持.

But prior to CORS, browsers wouldn’t allow you to do a cross-origin application/json POST at all, and so servers could assume they wouldn’t receive them. That’s why a CORS preflight is required for those types of "new" requests and not for the "old" ones—to give a heads-up to the server that this is a different "new" type of request that they must explicitly opt-in to supporting.

这篇关于为什么对于标准内容类型的POST请求，CORS中没有预检的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！