根据我的阅读，CSRF预防似乎侧重于（1）使GET请求无副作用，以及（2）仅使用带有CSRF令牌的POST请求来改变状态。但在我看来，这假设攻击者可能拥有的唯一目标是恶意更新受害者网站。如果攻击者只想要通过GET请求检索的信息怎么办？有人不能将受害者网站的敏感资源嵌入攻击网站并通过Javascript与其进行交互吗？
所以我的问题是（1）是可能的，（2）你如何防止它？
答案 0 :(得分：2)
如果攻击者有办法接收服务器对受害者请求的响应（响应将被传输到受害者的浏览器，但不会传输给攻击者），则攻击者可能会受益于CSRF GET请求。 / p>
但是，在典型的CSRF方案中，攻击者无法访问响应，因为它是从服务器传输到受害者的Web浏览器（而不是传输给攻击者）。通常意图是导致某些状态更改，例如启动付款，发送电子邮件等，这通常由客户端使用PUT，POST，PATCH或DELETE等方法发出HTTP请求来启动。
答案 1 :(得分：2)
攻击者可以在其网页上包含以下脚本：
$.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 Hijacking存在问题，但是你必须回到Firefox 3才能找到易受此攻击的浏览器。见Is JSON Hijacking still an issue in modern browsers?