CSRF
概念
CSRF(Cross-site request forgery)跨站请求伪造,黑客利用已经登录的用户,诱使其访问或者登录某个早已构造好的恶意链接或者页面,然后在用户毫不知情的情况下,以用户的名义完成了非用户本意的非法操作。这种攻击我们也被称为”One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用行为。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。
CSRF 学习理解
其实一个CSRF漏洞攻击的实现,其需要由“三个部分”来构成。
(1) 有一个无需后台验证的前台或后台数据修改或新增请求的漏洞存在;
(2) 伪装数据操作请求的恶意链接或者页面;
(3) 诱使用户主动访问或登录恶意链接,触发非法操作;
第一部分:漏洞的存在
关键字:跨站请求漏洞存(CSR:Cross Site Request)
如果需要CSRF攻击能够成功,首先就需要目标站点或系统存在一个可以进行数据修改或者新增操作,且此操作被提交后台后的过程中,其未提供任何身份识别或校验的参数。后台只要收到请求,就立即下发数据修改或新增的操作;
以上漏洞情况的存在,出现比较多的场景有用户密码的修改、购物地址的修改或后台管理账户的新增等等操作过程中。
如何判断是否存在CSRF漏洞:
1.查看数据包中是否存在Token参数
2.看是否验证来源地址
①Referer向下一个页面传递你是从哪一个URL地址进来的
②来源无法被伪造
第二部分:漏洞利用的伪装
关键字:伪装请求(F:forgery)
CSRF漏洞存在了,如果需要真正的被利用,还需要对“修改或新增”数据操作请求的伪装,此时恶意攻击者只要将伪装好的“数据修改或新增”的请求发送给被攻击者,或者通过社工的方式诱使被攻击者在其cookie还生效的情况下点击了此请求链接,即可触发csrf漏洞,成功修改或新增当前用户的数据信息,如修改当前用户的密码、又或者是当前用户为后台管理员,触发漏洞后新增了一个后台管理员。
第三部分:用户非本意的操作
关键字:非本意操作
当前用户在不知情的情况下,访问了黑客恶意构造的页面或在链接,即在非本意的情况下完成黑客想完成的“非法操作”,实现了对当前用户个人信息的恶意操作。
CSRF 漏洞理解小结
小结:构造一个恶意链接或者html页面
说一千道一万,我们要明白“CSRF漏洞的目的”是什么,其实就是利用已存在的漏洞构造了一个“恶意链接”或“html页面”,然后诱使用户点击触发此漏洞。
那么说的再明白点,就是被检测的目标站点存在一个漏洞(CSRF),攻击者利用此类漏洞伪装了一个链接或者html页面,诱使被攻击者在登录的情况下(即当前cookie有效的情况下)点击了此伪装请求,随后在用户不知情的情况下完成了对当前用户数据的修改或者新增操作,而被修改的信息可能是用户的密码、关键信息又或者新增后台管理员等。
CSRF 漏洞防护
其实现在有关CSRF漏洞防护已经是比较成熟了,其主要防护的思路就是需要在进行后台数据修改操作的过程中,添加对当前用户身份的有效验证措施,而不能仅限于cookie的识别,这里简单的罗列了下防护措施如下。
(1) 来源校验
使用http请求头中referer来源,对客户端源进行身份校验,此方法早期使用比较多,但是仍然容易被绕过,所以这里并不建议使用。
(2) 用户token 校验
添加基于当前用户身份的有效tokens随机验证机制,即在向后端提交数据操作请求时,添加基于当前用户的随机token校验值,此种校验方法当前使用比较多;
(3)当前用户密码验证
在修改关键信息时,要求当前用户输入其自身的密码,以验证当前用户身份的真伪,防止未授权的恶意操作
(4)添加验证机制
在请求数据的提交前,需填写验证码信息提交,以增加对用户来源的有效验证,防止恶意未授权的操作产生。
基础知识扩展:
后端接收的三种形式:get、post、request
php中$_REQUEST、$_POST、$_GET的区别
- $_REQUEST
php中$_REQUEST可以获取以POST方法和GET方法提交的数据,缺点:速度比较慢 。
$_GET
用来获取由浏览器通过GET方法提交的数据。
GET方法他是通过把参数数据加在提交表单的action属性所指的URL中,值和表单内每个字段一一对应,然 后在URL中可以看到,但是有如下缺点:
安全性不好,在URL中可以看得到
传送数据量较小,不能大于2KB。
$_POST
用来获取由浏览器通过POST方法提交的数据。
POST方法他是通过HTTP POST机制,将表单的各个字段放置在HTTP HEADER内一起传送到action属性所指的URL地址中,用户看不到这个过程。
他提交的大小一般来说不受限制,但是具体根据服务器的不同,还是略有不同。相对于_GET方式安全性略高
4.$_REQUEST、$_POST、$_GET 的区别和联系
$_REQUEST[“参数”]具用$_POST[“参数”] $_GET[“参数”]的功能,但是$_REQUEST[“参数”]比较慢。
通过post和get方法提交的所有数据都可以通过$_REQUEST数组[“参数”]获得
一. get与post请求的不同
GET方式提交数据的特点:
get方式在url后面拼接参数,只能以文本的形式传递数据
传递的数据量小,4KB左右(不同浏览器会有差异)
安全性低,会将数据显示在地址栏
速度快,通常用于对安全性要求不高的请求
post 方式 :
1-安全性比较高
2-传递数据量大,请求对数据长度没有要求
3-请求不会被缓存,也不会保留在浏览器历史记录中
用于:密码等安全性要求比较高的场合,提交的数据量比较大:发布文章,上传文件。
二. $_GET获取get数据
GET方式提交数据的格式
格式:index.php?userName=jack&password=123
参数名与参数值之间没有空格
参数值不需要使用单双引号包括
三. $_POST获取post数据
表单数据是通过请求体传递到服务端的
我们在界面上看不到,可以提交任何类型的数据包括文件,由于界面上看不见,浏览器也不储存,所以更安全
在burp suite中制作csrf的HTML文档
复现
案例一: (pikachu CSRF复现)
CSRF(get型)
根据提示,账号有vince/allen/kobe/grady/kevin/lucy/lili,密码全部是123456
我们随机登录一个账户 lili 123456来到个人中心修改个人信息
随机修改一个参数值,例如性别修改为xxxx
点击submit抓包
由请求包可以看出该请求方式为get类型
构造playload
1 | http://192.168.232.130/pikachu/vul/csrf/csrfget/csrf_get.php?sex=xxxx&phonenum=18626545453&add=chaind&email=viince@pikachu.com&submit=submit |
此时我们playload已经构造好了,就可以实行攻击了
如果此时有用户处于登录状态并点击了我们的链接,就会修改内容为我们链接中的内容
实现
我们模拟登录一个账户vince 123456点击playload中的链接
点击连接后可以看见性别发生了改变
CSRF(post型)
同样登录一个账户修改信息抓包,可以看见这个时候请求方式已经变为post型了,我们已经不能通过get方式去进行构造playload
playload
用burpsuite选择生成csrf poc,会生成一段HTML代码,然后copy下来制作成一个页面链接
用户点击链接后,就会修改信息
CSRF(token)
关于token的介绍可以参考下这篇文章:https://www.cnblogs.com/lufeiludaima/p/pz20190203.html
当我们在加入token后,再次构造的playload就会携带token进行判断请求,但是token是一个随机值,当请求后会与session中的token相互比较,并且token具有时效性,一段时间就会过时
可以看见我们重新构造的playload加入了随机token进行携带判断,这样的话就防止了csrf
案例二: (属于post类型的)
新增收货地址为案列
请勿复现利用(未授权)
xx商城存在csrf漏洞
能够抓包构造CSRF的HTML文件,当用户处于等录状态时,就能通过通过抓包的文件(例如:增加地址,删除地址等),制作而成的HTML诱导用户打开(必须处于相同浏览器–(主要是浏览器中的cookie缓存)),从而做到增加,删除地址等。
例如:
- 在增加收货地址处抓包,并通过engagement tools–àgenerate CSRF poc
- 将所生成的HTML文件copy下来,粘贴到记事本,将后缀换成HTML
- 将该记事本用当前登录的用户的浏览器打开(此处是谷歌)
- 点击按钮,添加成功
- 可看到收货地址有我们添加的收货地址
案例三: (get类型)
下面为我自己搭建的一个开源商城系统,在其模板选择处删除模板抓包
就会获取到如上的一个get请求包,将其URL地址复制下来
我们此时就可以对“default——20201014”进行修改掉我们想要删除的内容
例如在www.cdclhh.com:8986下新建一个xxx文件,此时我们将URL地址改为
当管理员处于登录状态下点击上述的地址就能删除xxx文件
我们设想一下如何将删除的内容改为../../…/.//././…/…/一直往上延伸,是不是可以删除整个根目录乃至C盘,引起整个系统的崩溃,可见危害之大