security - CORS:为什么没有带有 Content-Type:text/plain 的 POST 飞行前请求

Question

在阅读了很多关于 CORS 和飞行前请求的内容后，我仍然不太明白为什么进行飞行前会有一些异常(exception)。为什么 Content-Type 是“text/plain”或“application/json”很重要？

如果我猜对了，CORS 的值(value)是限制返回的数据(它不关心 POST 是否破坏了数据库，它只关心浏览器无法读取该操作的输出)。但如果这是真的(可能不是)，为什么会有飞行前请求？仅在响应中检查像“Access-Control-Allow-Cross-Origin-Request: true”这样的 header 是不够的？

迄今为止我在以下位置找到的最佳答案:CORS - What is the motivation behind introducing preflight requests?问题，但对我来说仍然有点困惑。

Answer 1

Why does it matter if the Content-Type is 'text/plain' or 'application/json'?

三人 content types ( enctype ) supported by a form如下面所述:

application/x-www-form-urlencoded

multipart/form-data

text/plain

如果 Web 服务器上的处理程序接收到一个表单，并且它不是上述内容类型之一，那么可以假设它是发送表单的 AJAX 请求，而不是 HTML <form />标签。

因此，如果现有的 pre-CORS 系统使用内容类型作为确保请求不是跨站点的方法，以防止 Cross-Site Request Forgery (CSRF) ，那么 CORS 规范的作者不想在现有网站中引入任何新的安全漏洞。他们通过坚持此类请求启动预检以确保浏览器和服务器首先兼容 CORS 来做到这一点。

It doesn't care if the POST destroyed the database, it only cares that the browser can't read the output of that operation

非常正确。默认浏览器遵守 Same Origin Policy . CORS 放宽了这个限制，允许另一个 Origin 读取 AJAX 做出的响应。

why there are pre-flight requests at all?

如前所述，为了确保客户端和服务器都兼容 CORS，而不仅仅是发送的 HTML 表单总是能够跨域提交。

例如这一直有效。 example.com上的表格发布到 example.org :

<form method="post" action="//example.org/handler.php" />

Wouldn't suffice to just check for a header like 'Access-Control-Allow-Cross-Origin-Request: true' in the response?

因为 CSRF 向量。通过检查浏览器是否可以发送预检，确保跨域请求在浏览器发送之前获得授权(通过检查 CORS 响应 header )。这使浏览器能够保护当前用户的 session - 请记住，这里的攻击者不是运行浏览器的人，受害者正在 CSRF 攻击中运行浏览器，因此被操纵的浏览器无法正确检查 CORS header 或欺骗预检对于攻击者自行运行没有任何好处。同样，预检启用 CSRF 缓解，例如 custom headers上类。

总结:

HTML 表单跨域

只能与特定的一起发送 enctype的

不能有自定义标题

浏览器将在没有预检的情况下发送它，因为有关 <form> 的所有信息提交将是标准的(或 "simple"，正如 CORS 所说)

如果服务器处理程序收到来自此类表单的请求，它将对其采取行动

AJAX 跨域

只能通过 CORS

一些浏览器的早期版本，如 IE 8 & 9可以发送跨域请求，但不能使用非标准 header 或 enctype的

可以有自定义标题和 enctype位于 fully supported browsers

为了确保跨域 AJAX 请求不会欺骗同源 AJAX 请求(请记住，跨域过去是不可能的)，如果 AJAX 请求不是 simple然后浏览器将发送预检以确保这是允许的

如果服务器处理程序收到一个请求，它将对其采取行动，但前提是它通过了预检因为初始请求将使用 OPTIONS 动词发出，直到浏览器同意服务器正在谈论 CORS 才会发送实际的 GET 或 POST