反CSRF cookie?

fre*_*hie 3 asp.net security csrf

我正在构建一个使用大量ajax的应用程序.大多数反CSRF解决方案都围绕在视图状态中放置一些信息并在帖子上处理这些数据.但是,我无法访问ajax调用中的viewstate.

我计划生成GUID以在cookie和会话状态中插入令牌,在用户注销时使cookie过期,在每个请求时修改cookie令牌和会话状态,并使用httpmodule通过比较什么来完成工作在进入Web服务或页面方法之前,在与会话中返回的内容的会话中.

这会使我的应用CSRF证明吗?

谢谢.

小智 9

不, "反CSRF"和"cookie"不一起去.正如Thilo如此简明扼要地指出:

Cookie是让CSRF首先工作的原因......

一个很好的初步读物是Cross-Site Request Forgery文章,该文章总结了CSRF的大部分内容:

如果Bob的银行将他的身份验证信息保存在cookie中,并且如果cookie未过期,那么Bob的浏览器尝试加载图像将提交带有cookie的提款表单,从而在没有Bob批准的情况下授权交易.

问题是浏览器总是有"有效的cookie".然而,GUID - 实际上只是一个随机数 - 可以通过其他方式传服务器......这实际上就是它在视图状态中的状态.

CSRF预防机制#1(每个维基百科):

在所有表单提交和副作用URL中要求使用特定于用户的秘密令牌可防止CSRF; 攻击者的网站无法在其提交的内容中加入正确的令牌.

重要的是这个秘密(希望是为了避免重放攻击的随机数)是发送的数据(URI或内容)的一部分,而不是通过cookie传输的.

快乐的编码.


考虑一下这可以实现的方法:

让服务器在建立会话时生成一个nonce(并将其存储在会话数据中).然后在每个AJAX请求上发送此nonce - 作为URI的一部分或作为一些POST数据*.

服务器服务器应仅基于此现时接受/拒绝请求,并且是否与存储在会话状态中的随机数匹配.(会话状态可以通过cookie维护:假设nonce是秘密的,它是通过不同的通道传输的nonce将阻止这个CSRF.)

nonce可以通过多种方式传输到客户端,包括但不限于隐藏字段,JavaScript变量,直接链接操作,甚至cookie(只读!不用于验证!).

*当然,有许多重叠的安全问题(和预防机制)正在发挥作用,简单的XSS可以绕过最精细的反CSFR.考虑使用经过充分测试的框架可能值得考虑......