这种破解 CSRF 防御的方法是否可行？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 3004 days ago, the information mentioned may be changed or developed.

我们首先统一一下口径：站点 A：被攻击的网站站点 B：伪造请求的网站

一般网站的防御方法是：判断请求中的 token 和 cookie 中的 token 是否相同，相同则表示请求发起者和会话用户是同一个人。

这种防御方法可行的原因是：站点 B 无法获取到站点 A 的 cookie，所以无法在请求中添加 token。

但，我们假设站点 B 知道站点 A 的某个页面表单里有隐藏的 token 字段，那么，站点 B 在自己的页面中写一个隐藏的 iframe 去请求这个页面。（这里有一个问题，iframe 会创建新的会话吗？但不管会不会，都有如下可能）

iframe 不会生成新的会话。那么对于用户而言，假设用户在访问站点 A 后没有关闭站点又去访问了站点 B，那么站点 B 中的 iframe 和站点 A 属于同一个会话，也就是说他们的 token 相同。这个时候站点 B 通过预先写好的脚本去获取到 iframe 中的 token，然后在伪造的请求中加入这个 token，能否成功？
iframe 会生成新的会话。那也就是说站点 B 的 iframe 中的 token 和站点 A 的 token 值是不相同的，但是可以使用以下方法去伪造请求：站点 B 不是直接在页面中添加伪造请求，而是在 iframe 里去添加伪造请求，由于 iframe 中是站点 A 的会话，所以请求会带着站点 A 的 cookie 一起发出去，由于 iframe 和站点 A 共用一套 cookie （因为同域），所以就成功盗用了用户的身份。这种方法可行吗？

Supplement 1 · Feb 5, 2018

经过验证，iframe 并不会产生新的会话，而是会沿用未关闭的站点 A 的会话。

也就是说，iframe 中的 token 已经可见，关键在于脚本是否能够获取到。

Supplement 2 · Feb 5, 2018

看来我描述的让有些v友产生了误解，我修改下上述验证：

经过验证，iframe 并不会产生新的会话，而是会沿用未关闭的站点 A 的会话。

也就是说，iframe 中 表单的 token 字段 已经可见，关键在于脚本是否能够获取到。

Supplement 3 · Feb 5, 2018

不过好像 Chrome 扩展可以拿到 iframe 中的内容，黑客或许可以这么干，当用户访问站点 b 的时候，站点 b 要求安装扩展，该扩展拿到 token 上传服务端，然后 websocket 将 token 发给站点 b，并告知站点 b 可以去伪造请求了。

站点

token

iframe

请求

20 replies • 2018-02-06 08:17:58 +08:00

40huo

Feb 5, 2018 via Android

你说的这个应该在 xss 和同源策略的范围讨论，和 csrf 已经关系不大了

Feb 5, 2018

> 这里有一个问题，iframe 会创建新的会话吗？
会，但是并不能跨域进行对 iframe 的任何操作。所以取不到 token。

lxy

Feb 5, 2018

因为同源策略，所以你无法获取 token
>Scripts trying to access a frame's content are subject to the same-origin policy, and cannot access most of the properties in the other window object if it was loaded from a different domain.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe

yyfearth

Feb 5, 2018 via iPhone

这个首先你就没办法访问跨域的 iframe 所以你说的方法从根本上就不可能

alvinbone88

Feb 5, 2018

一般带有 CSRF 防御的页面通常会在 HTTP 的响应头里加一个 X-Frame-Options 来阻止页面在 iframe 中加载，所以把页面嵌在 iframe 里根本不可能，得到的结果就是一片空白
另外提醒一下，在页面中加<meta http-equiv="X-Frame-Options" content="deny">会被部分浏览器忽略掉（比如 IE ）

zjsxwc

Feb 5, 2018

```
一般网站的防御方法是：判断请求中的 token 和 cookie 中的 token 是否相同，相同则表示请求发起者和会话用户是同一个人。
```

楼主你一开始就搞错了吧，不是判断 cookie 的 token 而是服务器端 session 里的 token

xvrzhao

Feb 5, 2018

@zjsxwc https://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html

MeteorCat

Feb 5, 2018 via Android

首先，其实就目前来说所有语言的 Web 现代化框架都带有对这种方法的屏蔽，基本上都是内部页面表单会生成一个 hidden 的字段，确保这次提交是请求服务之后返回下来表单(虽然很多人都不用这个，因为基本上除非你直接网页就被挂马，否则内嵌而已 iframe 来提交表单基本上可以认定为小概率事件不做考虑)；其次就是如何内嵌 iframe 到页面做请求？楼主有真实案例？纸上得来终觉浅，绝知此事要躬行