为什么恶意站点在攻击之前不能通过GET获取CSRF令牌？

Question

为什么恶意站点在攻击之前不能通过GET获取CSRF令牌？

the*_*one 6 browser security ajax csrf csrf-protection

如果我理解正确,在CSRF攻击中,恶意网站A会告诉我的浏览器向网站B发送请求.我的浏览器会自动在该请求中包含我的B Cookie.虽然A看不到这些cookie,但如果我已经在B中进行了身份验证,则请求看起来是合法的,并且无论采取什么行动都会成功执行.为了避免这种情况,每当我访问包含表单的B页面时,我都会收到一个CSRF令牌.这个令牌与我的会话相关联,所以如果我向B发布一个POST,我必须包含这样的令牌; 否则B拒绝我的请求.此方案的好处是A将无法访问该令牌.

我有两个问题:

上面的描述是否正确？
如果是这样,为什么站点A不能首先告诉我的浏览器向G发送GET ,从响应中获取CSRF令牌,然后使用令牌立即向B发送POST ？请注意,令牌有效并与我的会话相关联,因为GET还包含我的所有B cookie.

谢谢!

Answer 1

Gab*_*yel 5

你的描述是正确的.

如果站点A告诉您的浏览器转到B并获取令牌,那很好,但因为它是跨域请求,A将无法访问Javascript中的令牌(这是一个浏览器功能).因此,当A告诉您的浏览器返回B并实际执行某些操作时,它仍然无法在请求中包含该令牌.

也就是说,除非B将令牌设置为cookie.显然,这将是有缺陷的,因为令牌cookie也将被发送,从而否定任何保护.因此,在这种情况下,令牌必须作为表单值或请求标头(或其他不像cookie一样自动发送)发送.

这也意味着如果B容易受到跨站脚本攻击,它也容易受到CSRF的攻击,因为令牌可能会被盗,但CSRF则是一个较小的问题.:)

感谢你的回答。我还不太明白的是这个“浏览器功能”（我想你指的是 CORS）。因为有很多网站进行跨域请求，他们实际上可以查看响应的内容。我能想到的最简单的例子是包含 src 指向不同域的图像。我不明白的是，服务器是否会为图像发送与页面不同的 Access-Control-Allow-Origin 标头，或者浏览器是否正在处理此问题。再次感谢。 (2认同)
实际上,该功能称为SOP,相同的原始策略.Javascript只能访问从页面本身下载的内容,除非其他站点发送CORS(跨源资源共享)标头以允许请求者访问.Javascript也无法访问跨源图像,但它们会显示给用户.类似地,可以在iframe中加载和显示另一个原点(除非发送x-frame-options,但这是一个不同的故事),但外部页面将无法访问iframe内容. (2认同)

归档时间：	9 年，2 月前
查看次数：	963 次
最近记录：	9 年，2 月前