根据我的阅读，CSRF 预防似乎侧重于 (1) 使 GET 请求无副作用和 (2) 仅使用带有 CSRF 令牌的 POST 请求来更改状态。不过，在我看来，这是假设攻击者的唯一目标可能是恶意更新受害者网站。如果攻击者只想要可以通过 GET 请求检索的信息怎么办？不能有人将受害者站点的敏感资源嵌入到攻击站点中并通过 Javascript 与之交互吗？
所以我的问题是（1）这可能吗，以及（2）你如何防止它？
【问题讨论】：
$.get('http://vulnerable.example.com/json')吗？
标签： javascript web csrf
攻击者可能在其页面上包含以下脚本：
$.get('http://vulnerable.example.com/json')
但是，由于Same Origin Policy，攻击者域上的 JavaScript 无法读取响应。同源策略检查域、协议和端口是否匹配——如果不匹配，JavaScript 将在尝试读取响应时遇到安全错误。例如，这是 Chrome 在尝试从另一个域访问 IFrame 时给出的警告 - 这与保护 JavaScript 响应的机制完全相同。
Uncaught SecurityError: Failed to read the 'contentDocument' property from 'HTMLIFrameElement': blocked a frame with origin "http://evil.com" from accessing a frame with origin "http://vulnerable.example.com". Protocols, domains, and ports must match.
因此，总而言之，POST 请求必须使用 CSRF 令牌，因为即使无法读取响应，仍会发出 POST 请求，并且 GET 请求通常不会引起关注，因为无法读取响应并且它们是非破坏性的. JSON 劫持存在问题，但您必须回到 Firefox 3 才能找到易受此攻击的浏览器。见Is JSON Hijacking still an issue in modern browsers?
【讨论】：
如果攻击者有办法接收服务器对受害者请求的响应（响应将被传输到受害者的浏览器，但不会传输给攻击者），那么攻击者可能会从 CSRF GET 请求中受益。
然而，在典型的 CSRF 场景中，攻击者无权访问响应，因为它是从服务器传输到受害者的 Web 浏览器（而不是传输给攻击者）。通常意图是引起一些状态变化，例如发起支付、发送电子邮件等，这通常由客户端使用 PUT、POST、PATCH 或 DELETE 等方法发出 HTTP 请求来发起。
【讨论】：