让我们从定义术语“起源”开始。页面的来源由三个独特的因素决定：主机名、协议和端口号。例如，由于协议不同http://test.com而https://test.com具有不同的起源。同样http://one.test.com，http://two.test.com由于主机名不同，因此来源也不同。对于在具有不同端口号的同一主机上运行的两个服务，源属性也不同，例如http://test.com:8081，http://test.com:8082它们被认为是不同的源。

同源策略 (SOP) 是一种浏览器级别的安全控制，它规定由一个源提供的文档或脚本如何与来自其他源的资源进行交互。基本上，它可以防止在一个来源下运行的脚本从另一个来源读取数据。

仍然允许跨域请求和表单提交，但不允许从其他来源读取数据。这意味着如果您在易受攻击的站点上执行 CSRF 攻击，从而导致某些服务器端状态更改（例如，用户创建、文档删除等），攻击将会成功，但您将无法读取响应。

简而言之，SOP 只会阻止读取来自不同来源的数据。它不包括用于执行 CSRF 攻击的跨域表单提交。

就使用 AJAX 执行跨域通信而言，还有一些其他的安全控制规定了通信。请参阅跨域资源共享。CORS 允许不同来源以受控方式通信和共享数据，并且 CORS 配置错误也可能导致安全漏洞。

请注意，SOP 不会阻止托管在不同域上的资源通过使用脚本标签、CSS 和图像标签嵌入到页面中。虽然这可能不允许直接读取内容，但加载和渲染的副作用可用于确定（部分）内容。另请注意，SOP 根本不涵盖 Websocket，因此可以进行跨站点读取。

PS取自我的博客。

同源策略 (SOP) 保留其他域的数据...

SOP 有两个部分：

1. 它可以防止源 A 上的脚本从源 B 读取数据。
2. 它可以防止源 A 上的站点向源 B 发送所谓的“简单”请求以外的任何内容。简单请求仅限于 GET 和 POST，并且只能修改少数标头。

...因此取消了 CSRF 的使用。

SOP 不能防止 CSRF。为什么？

1. CSRF 攻击是通过发送请求来完成的，而不是通过从响应中读取任何内容。事实上，您既不能也不需要阅读响应。
2. 你通常会在 CSRF 攻击中使用简单的请求。

如您所见，上述 SOP 实施的限制并不能阻止 CSRF 攻击。

现在考虑同源策略仅适用于 XMLHTTPRequest...

不，不是的。它适用于浏览器处理的所有数据。如果你使用 XMLHTTPRequest，一个普通的表单，或者 fetch API 是无关紧要的。同样的限制适用。

...因此，通过巧妙设计的表格，我可以发出 POST 请求，从而使 SOP 无效，因此需要 CSRF 令牌。

使用巧妙的表单，您可以发出执行 CSRF 攻击的 POST 请求，是的。这就是您需要特殊保护的原因，例如 CSRF 令牌。

现在有了所有这些，CSRF 是围绕 SOP 工作还是通过它工作？

我不确定 SOP 的“解决”或“通过”是什么意思。相反，让我这样说：CSRF 是可能的，因为浏览器允许您发送跨源 POST 请求。

站点 A 可以通过各种方式向不同的站点 B 发出请求，例如，将站点 B 的图像包含在站点 A 的 HTML 中（即<img src=http://B/...>）或使用表单或 Javascript 或 HTTP 重定向执行类似的操作。从一个站点发起但指向另一个站点的请求称为跨站点请求。

跨站点请求伪造 (CSRF) 意味着跨站点请求可能被滥用。这通常是这种情况，因为来自先前连接到站点 B 的现有会话 cookie 被发送到该站点上的每个请求，即使该请求是从站点 A（即跨站点）发起的。这意味着请求是使用登录到 B 端的用户身份执行的。成功的 CSRF 攻击意味着这样的跨站点请求可能会造成伤害，例如通过更改易受 CSRF 攻击的路由器中的 DNS 设置。

同源策略 (SOP) 不会使 CSRF 成为不可能，但它以某种方式限制了 CSRF 的影响，因为请求被发送到站点 B，但攻击者无法看到站点 B 的服务器返回的结果。因此 SOP 将 CSRF 设为只写，即 CSRF 可用于执行不需要的操作，但不能单独使用它从站点 B 泄露数据。例如，外部攻击者可能使用内部公司 Wiki 中的 CSRF 漏洞创建新的以现有用户的名义发帖或删除帖子，但由于 SOP，他无法读取内部 Wiki 的内容并将其发送回外部攻击者。

请注意，并非所有跨站点通信都受 SOP 限制。值得注意的是， Websocket 不受限制，因此站点 A 的攻击者有可能使用浏览器作为蹦床，以登录用户的权限与站点 B 的 Websocket 进行完全通信，即写入和读取数据。