DVWA系列之18 CSRF漏洞分析

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

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

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

可以看到这里在获取$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这个页面发起的请求。

在通常情况下，访问一个安全受限页面的请求应来自于同一个网站，比如需要访问 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***的方法：二次确认。

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

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