同源策略使 A.com 上的 JavaScript 无法从 B.com 读取内容。但是，同源策略不会阻止 A.com 上的 JavaScript 或 HTML 向 B.com 发送任意请求。为了防止这种情况，您需要一种CSRF 预防方法，例如如果系统不是盲的，它就不起作用的秘密令牌。

CSRF 的重点在于它会产生有用的副作用，例如更改用户密码或添加管理帐户。即使 CSRF 不是盲目的，（由于某种魔法，或者可能是错误配置的 CORS 或 crossdomain.xml 规则集）也没关系，因为响应可能会被丢弃，所有重要的是有用的副作用。

跨域发送 GET 和 POST 请求非常容易，如果 GET 请求产生副作用，那么它很容易受到 CSRF 的攻击。一个很好的例子是$_REQUEST用于所有输入的 PHP 应用程序。

是的，他们是盲人。同源策略防止托管在一个域中的页面使用一种协议 [有时还包括端口] 向不同的域/协议发出任意请求。因此，除非您的服务器支持CORS，否则攻击者将无法发出“CSRF Ajax 请求” 。使 CSRF 攻击成为可能的根本原因是同源策略的例外情况，即允许任何网站向任何主机发出的请求类型。

但是，同源策略的大多数例外情况不允许您对响应执行任何有用的操作（包括读取）：

• 您可以将图像设置src为另一个域，但响应将正确呈现为图像以供用户查看，或者根本不呈现任何内容；
• 您可以将脚本设置src为另一个域，但它会运行或导致语法错误或类似错误；
• 您可以链接到外部样式表，但不能以编程方式访问其内容；
• frame您可以在ou中包含另一个页面iframe，但由于同源策略无法访问其 DOM 内容；等等。

这就是为什么，正如其他人已经指出的那样，响应不是攻击者感兴趣的，而是请求可能产生的副作用。

首先，CSRF 攻击根本不需要任何 JavaScript。您可以使用纯 HTML 伪造任意请求，以通过简单图像或简单表单发送任意 GET 或 POST 请求。

JavaScript 只会有助于自动发送后一种表单，因为它不会像请求图像那样自动发送。但是您也可以设置表单的提交按钮以跨越整个页面并使其透明，这样用户就不会看到它，但如果他单击页面上的某个位置，表单将被发送。

在大多数情况下，发送伪造请求对攻击者来说就足够了，因为其目的只是为了代表受害者和会话上下文触发一个动作。为此，一个简单的 HTML 表单就足够了。

但是对于 JavaScript，同源策略开始发挥作用，这使得它变得更加困难。的起源是在文档的URI（即方案，主机和端口）确定。只有当两个文档或资源的来源相同时，这两个文档/资源才是同源的。如果它们不是同源，同源策略基本上不允许任何 XHR 请求或通过 DOM（例如框架）直接访问。

在XMLHttpRequest (XHR)的第二个版本中，与 Ajax 一起使用的技术，在Cross-Origin Resource Sharing中定义的某些情况下允许跨域请求。基本规则是允许简单的跨域请求，而其他请求需要在实际请求之前进行预检请求。该预检用于确定服务器是否会接受实际请求。仅当该预检请求成功时，才会发送实际请求。

然而，即使它只是一个简单的请求并且请求成功，服务器仍然可能不允许浏览器将响应提供给 JavaScript，再次通过 CORS 中定义的某些响应头字段。

至于 CSRF 攻击，尤其是后一种类型的跨域请求是值得的，因为它们将包含用户凭据，如 HTTP 身份验证信息、cookie 等，这些都是触发服务器上的特权操作所必需的。但除非资源允许此类跨域请求，否则浏览器将不允许 JavaScript 发送这些请求。

所以结论是：

• CSRF 不需要 JavaScript，但是它使自动利用变得更加容易。
• 由于不符合 JavaScript 要求的同源策略，简单的基于 HTML 的请求伪造更有希望。
• 只有使用 JavaScript 才能读取响应，但它需要资源允许，尤其是在需要用户凭据的情况下。