10. CSRF 攻击实战

10.1 CSRF 攻击概述

  CSRF 全称跨站脚本请求伪造攻击,指的是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去运行。
  
  与 XSS 相比,CSRF 的特点在于欺骗用户自己主动访问站点,在不知情的情况下执行攻击者希望自己执行的功能。有一个非常形象的例子可以说明什么是 CSRF 攻击。假设某银行的网银地址是 http://www.bank.com ,该网银处理转账功能的页面地址为 http://www.bank.com/trans.jsp ,该页面使用 GET 方式提交参数。再假设该网银的用户 A 要转账 3000000 元给 B 用户,所以 URL 就是 http://www.bank.com/trans.jsp?payer=A&payee=B&amount=3000000 。按照这个原理,任何人只要访问了这个 URL ,就会触发 A 给 B 转账 3000000 的操作,但这很明显是不可能的,所以银行的网站要做身份验证。一般比较常见的验证机制是服务器会检查提交这个 URL 的用户的浏览器,付款人是否处于登录状态,如果处于登录状态则判断这个请求是付款人自己发起的,属于合法请求;而如果未处于登录状态,则判断为非法请求,予以拒绝。这个验证机制看起来似乎很安全了,但其实还是有很大的漏洞。假设 A 和 B 是互相认识的。B 通过微信把该 URL 发送给 A,A 对 B 没有任何怀疑,直接点击了这个链接。而恰巧 A 正好登录了自己的网银还没有退出,这个时候就能成功的通过银行网站服务器的验证机制,触发转账 3000000 给 B 的操作。
  
  在该案例中,B 成功利用了网站服务器只能检查发起请求的是不是用户的浏览器,而无法检查发起请求的是不是用户本意的这一漏洞。而这就是典型的 CSRF 攻击。在实际环境中,黑客经常使用 CSRF 攻击来诱使用户以自己的身份在论坛或微博上发帖,或者是诱使用户在自己的网站上创建一个黑客预先设计好的管理员账户,从而拿到网站后台权限。

  

10.2 Low 级别 CSRF 攻击实战

  1. 安全级别设置为 Low,点击 CSRF 按钮,进入反射型 XSS 攻击模块,如图 10-1。


    图 10-1

  2. 该页面可以发现是一个修改密码的页面。我们尝试修改一下密码,发现可以成功修改。并且观察 URL 可以发现修改密码的信息提交是通过 GET 方式实现的,如图 10-2。


    图 10-2

  3. 复制当前 URL,在浏览器上新开一个标签页,粘贴 URL 后,把 URL 中的 password_newpassword_conf 字段手动更改为自己想要的密码,提交后发现可以成功修改密码, 说明 CSRF 攻击成功。也说明了在 Low 级别中,网站不对 CSRF 做任何防御,如图 10-3。


    图 10-3


10.3 Medium 级别 CSRF 攻击实战

  1. 安全级别设置为 Medium,点击 CSRF 按钮,进入练习页面后,直接尝试复制 URL 到新标签页的方法尝试修改密码,发现未能成功,如图 10-4


    图 10-4

  2. 检查源码,发现服务器做了验证,对用户提交请求的 Referer 字段进行检查,要求 Referfer 必须是本服务器自己的主机名,如图 10-5。考虑到当前修改密码的功能中,提交请求和处理请求全部是在同一个页面完成,所以正常修改密码的请求,Referer 字段确实应该是本机的主机名。但是攻击者诱骗受害者点击提交的请求,Referer 一定是空值,所以无法通过服务器的验证。


    图 10-5

  3. 既然服务器验证了 Referfer,要绕过这个防御,就需要修改和伪造 Referer 了。在 Kali 中运行终端命令界面,键入命令 service apache2 start 开启 Web 服务,并进入到 Web 根目录创建一个与靶机主机名同名的 html 文件,如图 10-6。(由于并没有 DNS 做域名解析,所以演示中的文件名是用的靶机服务器的 IP 地址)


    图 10-6

  4. 在创建的 html 文件中,创建一个 iframe 标签,把修改密码的 URL 粘贴到 iframe 的 src 属性中,并设置为自己想要的密码,如图 10-7。


    图 10-7

  5. 在浏览器中访问攻击机上创建的这个页面 URL,发现可以成功修改密码,如图 10-8。


    图 10-8


10.4 High 级别 CSRF 攻击实战

  1. 安全级别设置为 High,点击 CSRF 按钮,进入练习页面后,直接尝试复制 URL 到新标签页的方法尝试修改密码,发现直接跳回到原页面,未能成功,如图 10-9。


    图 10-9

  2. 查看源码,发现加入了随机 Token 检查机制,如图 10-10。服务器每次向客户端返回修改密码页面都会给客户端产生一个随机的 Token 值,客户端修改密码时,需要携带该 Token,服务器如果检查发现用户携带的 Token 和它产生的不一样,就会判断为攻击行为,拒绝执行。考虑到 CSRF 攻击是诱使用户区点击链接发起的攻击,所以就算能通过脚本自动获取 Token,但也无法拦截客户的请求再把 Token 值插入到客户的请求包中,所以这里单纯靠 CSRF 攻击已经无法完成了。


    图 10-10


10.5 Impossible 级别 CSRF 攻击实战

  安全级别设置为 High,点击 CSRF 按钮,发现当前页面中要修改用户密码,必须先正确输入用户当前的密码。在不知道当前密码的情况下,没有办法完成 CSRF 攻击,如图 10-11。
  


图 10-11