只想从知道的人那里获得输入。我正在考虑CSRF漏洞,以及我知道与之抗衡的最流行的方法。该方法是在返回的html中创建一个令牌并添加一个具有相同值的cookie。所以如果一个脚本试图做一个职位,他们将have to guess the token thats embedded in the web page
为它成功。CSRF漏洞/ cookies问题
但是,如果他们针对特定的网站,为什么他们不能只用一个脚本,
- 调用页面上的get(cookie将被退回即使脚本不能访问它)
- 解析HTML并得到令牌
- 呼吁在它该令牌(即回来将被送回)
- 他们已经成功提交表单而不需用户知识的cookie后
脚本不需要知道cookie的内容,它只是使用cookie始终来回发送的事实。
缺少什么我在这里?这不可能吗?我认为如果你仔细想想,这很可怕。
下面这一行不需要读来回答这个问题:)
的事实是,认证是基于饼干,我认为这是主要的方式验证当前正在发生做此漏洞的银行。
我能想到的另一个解决方案是在页面级别进行身份验证。所以 当他们登录返回的html时,会在其中包含该标记。他们点击的每个链接都包含该令牌,因此当Web服务器收到请求时,它可以识别用户/会话。问题在于,如果他们使用除此之外的任何导航,他们将是'未经验证的'(例如,输入一个url),但它在url中看起来不太好,因为它可能看起来像这样:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
但我明白,如果安全性更重要,那么一个漂亮的URL是第二位的。
我不知道关于cookie的所有信息,但如果用户代理对cookie更小心一点呢?
例如,如果cookie发送取决于标签怎么办?我们现在都使用标签冲浪,对吧?那么如果cookie的范围是标签呢?所以如果我有我的银行网站在标签1上打开,并且我在标签2上冲浪,任何脚本调用获取/帖子 标签2将只发送标签2中产生的曲奇。
或者如果cookie被存储/域。所以当我在example.com上时,任何返回到example.com cookie集合的cookie都会返回。然后当我在www.mybankingsite.com上时,所有的cookies都会被放入mybankingsite.com收藏。因此,如果我访问example.com并运行调用get/post的脚本,用户代理将仅发送example.com cookie。这与发送请求域的cookie不同。例如。如果脚本在example.com的网页中调用mybankingsite.com的获取,用户代理将不会发送mybankingsite.com cookie。
我知道我在什么用户做代理无法控制,但我只是探索的可能性
好吧,你可以避免这种情况,只接受对该URL的Http后处理,但它确实打开了一个脚本可以访问它的DOM的事实,并且如果一个元素可以从另一个站点获取信息,那么你可以被入侵 – Jose 2010-07-01 20:05:40