GET请求的CSRF预防
从我读到的内容来看，CSRF预防似乎集中于（1）使GET请求免于副作用，（2）仅使用带CSRF令牌的POST请求来改变状态。 但在我看来，这假定攻击者可能拥有的唯一目标是恶意更新受害者网站。 如果攻击者只想获取可通过GET请求获取的信息呢？ 难道有人无法将来自受害者站点的敏感资源嵌入攻击网站并通过Javascript与其交互？
所以我的问题是（1）是否可能，以及（2）你如何防止它？
攻击者可能在其页面上包含以下脚本：
$.get('http://vulnerable.example.com/json')
但是，由于同源策略，攻击者域中的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令牌，因为尽管无法读取响应，但GET请求通常不会引起关注，因为POST请求仍将生成，因为响应无法读取且不具有破坏性。 JSON劫持存在这个问题，但是你必须回到Firefox 3来找到一个容易受到这个问题影响的浏览器。 请参阅JSON劫持在现代浏览器中仍然是一个问题吗？
如果攻击者有办法接收服务器对受害者请求的响应（响应将传输给受害者的浏览器，但不会传输给攻击者），那么攻击者可能会从CSRF GET请求中受益。
但是，在典型的CSRF场景中，攻击者无法访问响应，因为它从服务器传输到受害者的Web浏览器（而不是传输给攻击者）。 通常意图是引起一些状态变化，例如发起付款，发送电子邮件等，这通常是由客户端使用PUT，POST，PATCH或DELETE等方法发起HTTP请求而发起的。
链接地址: http://www.djcxy.com/p/47775.html