渗透测试-跨站请求伪造(CSRF)之修改密码及防御方法

跨站请求伪造CSRF漏洞及防御方法

前言

一、什么是CSRF

CSRF被叫做跨站请求伪造，该怎么理解这句话呢，比如用户a在浏览器登录了账号，当他发送登录请求时候，服务器验证了账号密码，会返回给一个身份信息存放在cookie里面，浏览器保存，那么以后用户访问服务器带着这个cookie就行了。那么怎么产生攻击的呢，是用户在已经登录的状态下，访问了一个恶意的网站，带浏览器保存的cookie值向服务器发送了恶意请求，服务器会以为是用户的请求，其实这是用户不知情的请求。垮了两个站，一个是用户登录实际网站，一个是攻击者恶意构造网站，所以称作跨站请求伪造。

满足条件：
1.用户的登录了受信任的A网站，生成身份验证cookie值
2.不退出A网站访问了恶意网站B网站。
可能有的人就问恶意网站如果构造呢，这也是这个漏洞实现的一个需要考虑的地方.

具体流程：
首先张三在一个银行上有一个账户，她向李四转账1000元，那么向银行网站发送请求，请求如下 http://bank.hello/draw?moeny=zhangsan&amount=1000&for=lisi,同时攻击者小明在该网站也有账号，知道转账请求如上，所以攻击者构造了一个恶意网站，在张三登录网站之后，并且没有关闭情况下，诱导受害者点击图片，或者是一个链接，该恶意网站访问会发送一个请求http://bank.hello/draw?moeny=zhangsan&amount=1000&for=xiaoming，也就是说张三向小明转账1000元，因为这时张三还登录银行网站，身份认证信息cookie没有失效，银行会认为这是张三用户发送的一个正常请求，所以会执行命令转账功能。一般完成这个攻击通常需要搭配xss漏洞，需要在登录银行网站后进行弹窗，鼠标点击链接啊等等诱导用户点击。同时你还得知道一个敏感操作的一个请求url，不然怎么构造网站呢。

二、CSRF修改密码及防御方法

1.利用CSRF修改密码

这里我们用dvwa进行实验
打开dvwa，修改等级为低级

我们进行CSRF实验，打开跨站请求伪造(CSRF)实验

我们重新设置密码，用burp进行抓包

我们发送到repeater，我们将修改的密码修改为pass1，进行重发

我们注销登录，再重新将我们之前设置好的密码进行登录，之前设置的是pass


发现登录失败，我们再进行在burp修改的密码，进行登录一下

发现登录成功了，实验结束，漏洞利用成功。

2.CSRF防御方法

漏洞防御
CSRF防御有很多方式，每种方式各有利弊，目前有

检测referer防御CSRF
根据http协议，http协议有一个referer字段，referer 字段是记录你来源地址，比如你访问银行网站的请求转账功能url为：http://bank.hello/draw?moeny=zhangsan&amount=1000&for=lisi，那么你请求包里面referer字段记录的通常是bank.hello这个域名的地址，那么服务器在操作前检测一个这个字段如果和银行网站一个域名那么就认定来自自家网站发送的请求，就会执行该请求。因为攻击者构造的恶意网站是在自己的网站上，在攻击者网站发送请求，来源应该是攻击网站来源，服务器检测时候发现不匹配，就会拒绝请求。所以检测是一个防御CSRF的一种方法，但是它也有它的缺点

首先当你在使用检测referer字段来防御CSRF攻击时候，需要考虑使用的宽松referer防御还是严格的referer防御，

宽松referer防御就是有referer字段的进行检测，不对称拒绝访问，如果没有referer字段的就不检测，允许访问。

严格referer防御就是必须有referer字段，且进行检测，如果referer字段信息不对或者为空或者没有则拦截。

那么就存在问题了，因为referer字段是浏览器提供的，在http协议虽然是要有referer字段的，但是每个浏览器具体体现方式不一样，可以通过代理可以删除referer字段的，对于一些低版本浏览器，允许修改referer字段的，同时因为referer字段记录了用户 的来源地址，如果用户访问一下隐私网站，那么referer字段就会记录，对于用户来说觉得这侵犯他们的隐私，所以用户可以在浏览器里面设置在发送请求时候不提供referer字段。所以如果你采用宽松referer检测防御，就会导致referer检测的绕过，如果你使用严格referer检测，就会导致，一些用户没有办法正常访问网站，也会扼杀一些没有referer字段的合法请求。所以对于检测referer字段防御需要分情况讨论。

目前大部分网站都是http协议或者是https协议，相对比这两种协议，http请求里面不包含referer字段更为普遍，因为http可以抓包删除header，而https是不能删除header,并且在跨站请求和同站请求中，跨站请求要更多阻止referer，因为跨站请求涉及隐私泄露。如果网站是https协议，比如银行啊，金融网站可以用严格referer来防御CSRF,其手段也非常适合来防御登陆CSRF，因为通常情况下，登陆请求都是通过HTTPS协议发起的。如果网站是http协议，需要宽松referer防御，因为考虑到兼容性。

随机token验证防御CSRF
token验证过程是什么呢，当用户请求时，服务器会查看自己的仓库里面看看有没有token值，如果没有说明你今天第一次访问，那么会生成一个token值放在仓库里面，并且将token值给用户带回去，那么你下次请求时候，麻烦携带上这个token值，如果没有带，或者带了但是和我仓库token值不一样那么拒绝请求。如果你携带 了正确的token值，我会生成新的token值给你，并且将仓库的token值也替换掉，保持token值得唯一性。这个token值我们就一定要是随机加密拥有一定复杂程度的数据，不能别人轻易破解。相当于多了一个检查关口，除了验证cookie,还需要验证token，但由于cookie容易利用，所以多加一个检查。比如现在，除了你是否买票，还得看你健康码是不是绿的。

但是这种方法也有不好的地方，因为一个网站可以会有很多服务很多请求，那么就需要每个请求都配好token值，get请求需要放在url后面， post请求需要放在表单里面，需要在页面每次加载的时候，对于代码进行遍历，就是从上到下检查。在客户端 html 中，主要是有两个地方需要加上 token，一个是表单 form，另一个就是链接 a，所以对于代码中所有的 a 和 form 标签后加入 token。但是对于页面加载之后动态产生html代码是没有办法的，因为遍历结束了，这时候需要程序员手动加token值，这样想想就知道多麻烦。

还有一个不好地方就是有一些网站可以允许用户发布内容分享链接，那么请求结束之后，链接后面会有token值，如果这个用户是攻击者自己，发布是自己的网站，那么就可以拿到token，发动攻击。所以有的网站限制链接只能是自己网站，如果是别的网站不给予token值。不过有的可以通过referer这个字段拿到token值，referer上面已经说过了，检测来源的。

http头自定义属性防御CSRF
该方法和token原理是一样的，只不是是将token值放入http头部自定义属性中，通过XMLHttpRequest这个类,可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中，那么就节省了成本，不需要变量页面加载的dom树。通过XMLHttpRequest请求地址不会再浏览器显示，路径不会暴漏，但是也有不好地方，就是页面所有请求都要换成XMLHttpRequest请求，同时通过该类请求的页面浏览器不会记录，那么对于一些刷新，后退前进操作是不会有反应的，那么用户体验就不是很好了。

二次验证防御CSRF
当你在进行一些重要操作时候，比如转账，付钱让用户提供账号密码才可以继续下一步，不过用户体验就不好了。

以上是我对于CSRF漏洞以及防御理解，同时也借鉴了前辈的经验，仅供大家参考。

总结

本次实验简单介绍了CSRF漏洞原理和利用方法，以及防御方法，大家可以结合burp工具一起使用，提高对渗透测试的能力。