如果它只是阻止页面/脚本从另一个来源读取响应，我们不能只使用像 Burp 这样的代理侦听器或像 wireshark 这样的嗅探器在响应到达浏览器之前捕获响应（实现 SOP 的地方）吗？

这是两种不同类型的攻击。防止从另一个来源读取可防止evil.example.com用户访问过的攻击者站点 ( ) 向用户登录的站点 ( ) 发出 XHR 请求webmail.example.com并获取数据。在这种情况下，它会阻止其他网站阅读用户的电子邮件。

如果您可以将用户的机器配置为使用拦截代理，或者您可以将 Wireshark 设置为在用户网络上以混杂模式侦听，那么作为攻击者，您可能不需要跨域 XHR 请求 - 您可以正常观察交通。一个例外情况是POODLE等攻击。例如，如果您可以通过网络监听流量，但用户使用 SSL 连接到网站，您可能需要将 XHR 流量作为 MITM 注入，以便通过 POODLE 攻击向量一次解密一个字节。

同源策略在这里没有帮助，但如果它不存在，则不需要 MITM 攻击或 POODLE 向量。同源策略防御一些基于 Web 的攻击，否则这些攻击是可能的，仅此而已。

为什么服务器甚至会响应来自其他来源的此类请求？他们不应该只在启用跨域资源共享 (CORS) 时才响应吗？

是的，如果服务器只响应来自自己来源的请求，那将更加安全。但是，如果在新的 Web 服务器版本中将其作为标准实施，这将破坏大部分 Internet。也可以创建一个不发出跨源​​请求的浏览器。没有人会使用它，因为它不适用于许多网站。

事实上，您可以在大多数浏览器中禁用第 3 方 cookie。这实际上会使跨源 AJAX 请求匿名，因为不会发送任何 cookie。当然 Chrome 会阻止设置或读取 cookie，其他浏览器可能只会限制此类 cookie 的设置。当然如果使用其他的认证方式，比如基本的 HTTP 认证，这里就帮不上你了。但是，如果您尝试一下，在大多数情况下，您将能够看到哪些功能中断了。

为什么服务器甚至会响应来自其他来源的此类请求？

在解析标头之前不会读取 Origin 浏览器标头，并且此时浏览器已经发送了 cookie - 对跨源的任何限制都将在浏览器级别更好地实现，因为 Web 服务器将无法阻止它之前的请求已发送。

允许跨源请求是历史上的工作方式，需要平衡安全性和兼容性。CORS 的设计方式是，如果服务器不选择 CORS，则安全级别与使用 pre-CORS 浏览器相同。在 CORS 之前，站点可以通过表单或资源请求（但不能通过 XHR）向其他域发出请求，现在也是如此。如果您从服务器的角度考虑，XHR GET 请求与使用<img />标签包含来自另一个域的图像一样。XHR POST 请求与创建提交到另一个域的表单相同。

您可以配置您的服务器以阻止这些请求（例如使用 Origin 标头），这实际上是防止 CSRF 攻击的有效方法。不过，这应该根据具体情况进行，并且应该记住，此标头的存在可能因浏览器和版本而异（例如，不支持较旧的浏览器）。

请注意，这对您的示例没有帮助，因为在大多数情况下，MITM 可以简单地欺骗 Origin。

他们不应该只在启用跨域资源共享 (CORS) 时才响应吗？

跨源请求的所有问题都已通过某种方式得到解决，例如浏览器都遵循同源策略，网站使用令牌来防止 CSRF。这是网络 - 默认情况下不安全。如果在开发网站时考虑到安全性，则可以克服这些问题。

为什么服务器甚至会响应来自其他来源的此类请求？他们不应该只在启用跨域资源共享 (CORS) 时才响应吗？

<img src=对于服务器而言，CORS XHR 和通过包含资源（即<script src=）或由链接访问的资源（ ）触发的跨站点请求<a href=看起来都相似并且无法可靠地区分。这是由于 Web 的现有架构，您不能仅仅因为某些 Web 应用程序喜欢使用 CORS XHR 就期望所有服务器都改变行为。

如果可以通过这种方式访问​​资源，通常也不是问题。唯一真正的问题是，如果您可以欺骗用户及其浏览器在登录到该站点时使用 XHR 访问该站点（即浏览器发送会话 cookie），因为您可能会使用 XHR 提取敏感信息并将它们转发到攻击者。因此，在问题开始的地方添加了保护：浏览器在所有请求上都将会话 cookie 发送到外部站点，因此浏览器应确保只有在外部站点明确的情况下才能削弱同源策略（即从外部站点读取）同意它，即知道这个请求是跨域的，并且检查并允许这个来源。

CORS XHR 规则不会将浏览器用户视为潜在攻击者，因为该用户无论如何都可以访问资源。相反，它认为一些外部攻击者是问题所在，它试图从用户登录的站点中提取信息。这与 CSRF 类似，但 CSRF 仅用于触发操作而不是读取结果。因此，用户自己是否安装了一些 MITM 解决方案来观看流量并不重要。如果攻击者能够安装这样的东西，那确实是一种危险，但是攻击者根本不需要 XHR，因为经典的包含（<img src=等）已经足以触发对资源的访问。因此，不需要专门针对 CORS XHR 考虑这种攻击向量。

我们不能只使用像 Burp 这样的代理侦听器或像 wireshark 这样的嗅探器来在响应到达浏览器之前捕获响应吗

首先，跨站请求伪造 (CSRF) 攻击绝对不会假设或暗示攻击者可以拦截 (MITM) 网络连接。如果您可以中间人（MITM）您的受害者，那么 CSRF 攻击几乎是多余的，因为您可以只观察身份验证数据（例如会话 cookie）并自己登录，充其量 CSRF 可能有助于导致它们公开他们的身份验证数据，而无需等待他们访问您的目标站点。但总的来说，如果你有能力对受害者进行 MITM，那么你就有比常规 CSRF 更有效的攻击向量可用。

其次，即使您可以 MITM 受害者并且观察请求的响应（否则 SOP 会阻止）很有用，大多数有价值的目标也会使用 SSL/TLS。这将阻止您观察响应，并且如果您能够破坏 SSL/TLS（例如通过在他们的机器上安装恶意 CA 证书），那么您可能还有更好的攻击向量可用。

为什么服务器甚至会响应来自其他来源的此类请求？

执行 SOP 不是 Web 服务器的责任，它实际上只在 Web 浏览器的上下文中才有意义。Web 浏览器可以确定哪个页面正在发出哪个请求，但服务器不知道除了引用标头之外哪个页面正在发出请求，并且无法保证该数据的完整性。

至于为什么浏览器首先允许发出请求，我认为这是因为浏览器在Access-Control-Allow-Origin收到响应之前无法评估。