DVWA跨站请求伪造CSRF攻击全面分析

Posted 2021-10-21 abraham76

1、CSRF简介

   CSRF全称是Cross Site Request Forgery，跨站请求伪造。简单理解就是利用客户身份伪造请求，以达到指定目的。
   具体场景就是：假设A登陆了某游戏网站Game，那么Game网站就会返回一个cookie来记录用户身份，以后每次请求都会自动携带该cookie与Game服务器交互。然后攻击者B精心构造了一个链接或者网页，诱使用户点击，这时就会向Game服务器发送一个请求，而该请求是携带了cookie值的，服务器就会处理该请求。B的目的就达到了。
   CSRF攻击有2个必要前提（拿Game网站为例）：

1. 用户A必须登陆了Game网站，且保持登陆状态（不能退出登陆）；
2. 用户A必须要点击攻击者B的链接或访问B的网页。
   两者缺一不可，只有满足这两个条件，攻击才可能生效。

2、low

下面沿用上面的Game网站场景，A的前端页面是这样的：

B通过抓包分析（B也注册了Game网站，所以可以先在自己电脑上分析）：

可以发现，请求是通过get发送，没有携带token等验证，于是B直接复制源请求链接，写一个简单的html页面，里面写一个img标签，src属性为该链接，然后发布。这样，当用户A登陆Game网站，又访问了B的发布的网页，那么就会触发修改密码请求。A的密码就被修改了。

3、medium

通过查看源码（实际上B是看不到源码的，但是B可以这样去猜测）：

可以发现，Game的后端验证了请求头内的referer字段，检查referer里面是否包含Game服务器的域名。因为如果A访问了B的网站，那么referer字段就不会有Game的域名。这样就可以防止CSRF攻击。
   我看网上有很多解题的帖子和博客，他们给出的方法是通过抓包，然后修改referer字段，这样就可以绕过服务端的检查。如下面的文章：

但是这里有个很大的缺陷：在实际场景下，B无法抓取A发送的请求。要知道，B让A访问自己的网站，目的是触发伪造的请求，但是这个伪造的请求是A的浏览器发送给Game服务器的，和B没有关系。所以这种方法是纯粹为了做题而做题。
正确的绕过方法是：B只需将html文件名修改为Game的域名即可。例如：假设Game的域名为：game.com，那么只要来自Game网站的请求，其referer字段里面必然包含“game.com”这串字符。B的服务器是www.hack.com，虽然不包含game.com，但如果B把Index.html改为game.com.html。这样，B就成功绕过了Game服务器的检测。

4、high

这个级别加了token验证。单纯的使用CSRF攻击已经毫无办法。因为CSRF攻击本质就是：所有重要操作的相关参数，都可以被攻击者猜测到。也就是说，只要加入一个随机的黑客猜不到的值，就可以完美防御。这个token机制就是如此。在修改密码之前，会发给A一个随机的token值，后端会验证token值，如果不一致，直接不处理。
   网上有人给出这样的方法绕过：在页面里面嵌入iframe或者利用js脚本来请求修改密码的页面，这时服务器就会发送token值，然后获取到token值作为参数提交，这样就可以绕过token验证机制。
该方法看似完美，实则行不通。因为浏览器有一个安全机制叫：同源策略。同源策略定义是：如果两个 URL 的 protocol、port 和 host 都相同的话，则这两个 URL 是同源。拿http://www.game.com举例子，访问如下资源：

URL	结果	原因
http://www.game.com/dir/index.html	成功	只有路径不同
http://www.game.com/login/login.html	成功	只有路径不同
https://www.game.com/dir/index.html	失败	协议不同
https://www.game.com:81/dir/index.html	失败	端口不同
http://mail.game.com/dir/index.html	失败	主机不同

根据规则，攻击者B的服务器与Game肯定是不同源的，那么B就无法在自己的域下访问Game的页面，于是攻击无法达成。
   有人可能会奇怪，为什么前面的low和medium不会受到影响，不也访问了Game服务器吗？----那是因为有些标签不受同源策略的限制，比如a标签、img标签、script标签。不过经过测试，虽然img标签不受同源策略影响，但是实操过程中，我发现chrome浏览器依然阻止了img的跨域请求，并给出了安全提示，如图：

其中黄色部分是阻止了img的跨域引用，红色部分是同源策略限制访问。黄色部分是谷歌浏览器的安全措施，并非同源策略影响，提示里面也写了“可能包含CSRF攻击”，这就是今年7月份更新的机制（不禁感叹，浏览器的安全措施越来越健全，攻击越来越难了）。
    回到主题，既然受到同源策略限制，那么如何过这关呢？这个就需要结合XSS漏洞，这就是另外的事了。这里只讨论CSRF攻击，high这关单纯使用CSRF攻击是无解的。

5、impossible

这个级别还额外加了二次验证。如图：

可以看到，在修改密码前，需要输入原来的密码。在这种情况下，由于B不知道A的密码（要是知道A的密码，哪还有这么麻烦），所以即使可以绕过同源策略，获得token，也无法绕过原密码的验证。前面我们说了，CSRF攻击本质就是：重要操作的所有参数，都可以被攻击者猜测到。这里B无法知道A的密码，所以无法进行CSRF攻击。