Skip to main content
您好,欢迎光临IDC汇,需要什么服务器直接咨询客服,方便快捷。客服QQ 点击这里给我发消息
首页 > 服务器安全 »正文

DVWA系列之18 CSRF漏洞分析

服务器安全 webadmin 2020-07-26 08:51:58 查看评论 加入收藏

下面我们来查看一下low级别的CSRF源码:

DVWA系列之18 CSRF漏洞分析

代码中在获取了$pass_new和$pass_conf这两个变量之后,利用mysql_real_escape_string()函数进行了过滤,这样虽然可以防止SQL注入,但却无法阻止CSRF***,之后这两个变量便被直接代入UPDATE语句中执行了数据库更新操作。

下面再来分析一下medium级别的代码:

DVWA系列之18 CSRF漏洞分析

可以看到这里在获取$pass_new和$pass_conf这两个变量之前,先利用一个if语句来判断“$_SERVER['HTTP_REFERER']”的值是否是127.0.0.1。这是一种基本的防御CSRF***的方法:验证HTTP Referer字段。我们可以再次使用之前的方法来实施CSRF***,可以发现已经不起作用了。下面就来解释一下这种防御方法的原理。

根据HTTP协议,在HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。比如下面这个利用Burpsuite拦截到的数据包,数据要提交到的页面是upfile_Other.asp,而我们是通过Referer字段后的http://192168.80.131/upload_Other.asp这个页面发起的请求。

DVWA系列之18 CSRF漏洞分析

在通常情况下,访问一个安全受限页面的请求应来自于同一个网站,比如需要访问 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallor,用户必须先登陆 bank.example,然后通过点击页面上的按钮来触发转账事件。这时,该转帐请求的Referer值就会是转账按钮所在的页面的URL,通常是以bank.example域名开头的地址。而如果***要对银行网站实施CSRF***,他只能在他自己的网站构造请求,当用户通过***的网站发送请求到银行时,该请求的Referer是指向***自己的网站。因此,要防御CSRF***,银行网站只需要对于每一个转账请求验证其Referer值,如果是以bank.example开头的域名,则说明该请求是来自银行网站自己的请求,是合法的。如果Referer是其他网站的话,则有可能是***的CSRF***,拒绝该请求。

在DVWA中,管理员是通过本地地址127.0.0.1来访问密码修改页面的,因而对于任何一个修改密码的请求,如果其Referer不是127.0.0.1,那么就判断为CSRF***,而予以拒绝。

然而这种方法并非万无一失,由于Referer的值是由浏览器提供的,对于某些浏览器,可以利用一些方法来篡改Referer值。所以***完全可以把用户浏览器的Referer值修改为需要的地址,这样就可以通过验证,从而进行 CSRF ***。

另外即使***无法篡改Referer值,这种方法也仍然存在问题。因为Referer值会记录下用户的访问来源,有些用户认为这样会侵犯到他们自己的隐私权,特别是有些组织担心Referer值会把组织内网中的某些信息泄露到外网中。因此,用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时,网站会因为请求没有 Referer 值而认为是 CSRF ***,拒绝合法用户的访问。

总之,通过验证HTTP Referer字段来防止CSRF***是不可靠的,这也是为什么DVWA的medium级别采用这种防御方法的原因。但是如何修改用户端浏览器的Referer值来绕过防御,我暂时还没有查到相关资料,这个问题就暂且搁置,待以后再补上。

最后再来分析一下high级别,首先在界面上就可以看到不同:这里需要管理员首先输入当前密码,然后才能重新设置密码。这就是目前非常有效的一种防御CSRF***的方法:二次确认。

DVWA系列之18 CSRF漏洞分析

所谓二次确认,就是在调用某些功能时进行二次验证,如:删除用户时,产生一个提示对话框,提示“确定删除用户吗?”。转账操作时,要求用户输入二次密码。另外,设置验证码也可以起到相同的效果。

当二次验证后,即使用户打开漏洞CSRF***页面,也不会直接去执行,而需要用户再次输入才可以完成***。这样,当用户突然收到提示后,可能会心存怀疑,就不会再乖乖地中招。

上一篇: KNIME系统简介
下一篇: 返回列表
广告06

微信