只是想从知道的人那里得到意见。我正在考虑 CSRF 漏洞,以及我所知道的最流行的对抗它的方法。该方法是在返回的 html 中创建一个令牌,并添加一个具有相同值的 cookie。因此,如果脚本尝试发布帖子,他们会希望have to guess the token thats embedded in the web page
它成功。
但是,如果他们针对的是特定网站,为什么他们不能只使用一个脚本
- 在页面上调用 get (即使脚本无法访问 cookie 也会返回)
- 解析 html 并获取令牌
- 调用包含该令牌的帖子(返回的 cookie 将被发回)
- 他们在用户不知情的情况下成功提交了表单
脚本不需要知道 cookie 的内容,它只是利用了 cookie 一直来回发送的事实。
我在这里想念什么?这不可能吗?如果你仔细想想,我认为这很可怕。
在此行下方不需要阅读即可回答问题:)
这个漏洞基于这样一个事实,即身份验证是基于 cookie 完成的,我认为这是当前进行身份验证的主要方式。
我能想到的另一个解决方案是在页面级别进行身份验证。因此,当他们登录时,返回的 html 中将包含该令牌。他们单击的每个链接都包含该令牌,因此当 Web 服务器收到请求时,它可以识别用户/会话。它的问题是,如果他们使用除此之外的任何导航,他们将是“未经身份验证”(例如输入 url),它在 url 中看起来也不好看,因为它可能看起来像这样:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
但我确实明白,如果安全更重要,那么漂亮的 URL 就排在第二位。
我对cookies一无所知,但是如果用户代理对他们的cookies更加小心怎么办?
例如,如果发送的 cookie 取决于选项卡怎么办?我们现在都使用标签冲浪,对吧?那么如果 cookie 的范围是选项卡呢?因此,如果我在选项卡 1 上打开了我的银行网站并且我在选项卡 2 上冲浪,则在选项卡 2 上调用获取/发布的任何脚本都只会发送在选项卡 2 中累积的 cookie。
或者如果cookies被存储/域。因此,当我在 example.com 上时,任何返回的 cookie 都会进入 example.com cookie 集合。然后当我在 www.mybankingsite.com 上时,所有的 cookie 都会被放入 mybankingsite.com 集合中。因此,如果我访问 example.com 并运行一个调用 get/post 的脚本,用户代理将只发送 example.com cookie。这与发送请求域的 cookie 不同。例如,如果脚本在 example.com 的网页中调用 mybankingsite.com 的获取,则用户代理将不会发送 mybankingsite.com cookie。
我知道我无法控制用户代理的工作,但我只是在探索可能性