第56天：漏洞利用-CSRF请求伪造&Refere同源&置空&配合XSS&Token值校验&复用删除

原理

经典场景：

1
2
3
4
假设用户登录某银行网站后，未退出登录。
攻击者向用户发送一封邮件，内含一个恶意链接（如 https://bank.com/transfer?to=attacker&amount=1000）。
用户点击链接后，浏览器向银行服务器发送转账请求，同时自动携带用户的登录 Cookie。
银行服务器验证 Cookie 有效，认为是用户操作，执行转账。

第56天：WEB攻防-CSRF请求伪造&Referer同源&置空&配合XSS&Token值校验&复用删除

防护措施

1
2
3
--对敏感信息的操作增加安全的token；
--对敏感信息的操作增加安全的验证码；
--对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。

攻击条件：

1
2
3
4
条件：
1、需要请求伪造数据包（如果是后台功能点，要么进了后台研究，要么只能从白盒的角度进行研究了）
2、无过滤防护，有过滤防护能绕过
3、受害者需要触发（钓鱼）

CSRF常出现的功能点

1
2
3
4
5
6
7
8
9
10
11
留言板、论坛:用户发表、编辑、删除评论或帖子。

后台管理:管理员修改网站配置、用户权限、删除数据等操作。

用户中心:用户修改个人资料、密码、邮箱等敏感信息。

在线购物:用户添加、删除购物车商品，确认订单，修改收货地址等。

银行转账:用户在登录状态下，发起转账操作。

社交媒体:用户发布、删除动态，修改个人资料，发送私信等

CSRF-无检测防护-检测&生成&利用

检测：黑盒手工利用测试。白盒看代码校验（有无token，来源检测等）

生成：BurpSuite –>Engagement tools –>Generate CSRF Poc

利用：将文件防止自己的站点下，诱使受害者访问（或配合XSS 触发访问）

image-20250815105914426

image-20250815110707692

我这里使用的汉化的，所以有点差异，但是都差不多。

image-20250815110849267

这里要把这个选项进行勾选，然后删除下图中的代码，因为如果不删除在提交的时候就会有一个按钮，要受害者手动点击，所以要进行删除。

image-20250815111520574

然后上传到内网虚拟机上（实战中要上传到云服务器上），然后伪造一个界面诱使(组合XSS打一个组合拳)受害者访问，这里需要注意需要在受害者有身份验证没有失效的浏览器进行访问，不然成功不了：

1
http://192.168.111.128/test.html

image-20250815112323068

访问之后，回显如上。

image-20250815112341756

在来看用户这里，发现新增用户成功。

这样是没有防护的。

CSRF Referer 同源规则上传&XSS

这里使用zblog，用上面同样的方式，进行测试：

这里还存在token复用

image-20250815121223151

image-20250815121204518

这里就出现非法访问。

其类似原理如下图：

image-20250815122529946

就是检测了来源，但是这个是可以进行伪造的。

image-20250815123305739

进行抓包，发现来源是192.168.111.128这个地址，这里尝试将来源修改成本地地址。

image-20250815123703324

但是小迪修改之后，csrf攻击成功，我这里修改之后还是非法访问。

基于严谨的检测绕过&&基于不严谨的检测绕过

1
2
3
开发验证来源，无非两种逻辑，
一种是全部匹配，就是来源一定要是自己才可以（192.168.50.19）
还有一种就是，模糊匹配，就是包含（192.168.50.19）这个值就行

image-20250815124735912

上图这样的就是模糊匹配。

image-20250815124853551

那么实战中该怎么进行操作呢？总不能要受害者帮忙抓包改包吧。

绕过思路1（创建来源同名目录）

1
2
3
4
5
http://xxx.xxx.xxx.xxx/http://xxx.xxx.xxx.xxx/hack.html
就是创建一个http://xxx.xxx.xxx.xxx/的目录，这样就可以绕过来源检测，但是实战中这个创建目录的时候不允许有//这样的符号。

除非是可以只接受ip地址：xxx.xxx.xxx.xxx这样的格式。
但是这个有一个条件，就是只能是目标通过点击过来的时候，来源才会包含这个目录。

绕过思路2（置空）

1
或者你直接将Referer这个值给置空

绕过思路3（删除Referer）

1
2
3
直接从数据包中删除Referer这个参数
<meta name="referrer" content="no-referrer">
需要在POC中加上上面这个代码

image-20250815130655700

发现报错信息更过， 然后抓取数据包进行研究：

image-20250815130720104

确实没有来源头了，放包，攻击成功。

image-20250815130728442

还有最后一种比较实用的就是：

1
配合XSS，如果对方有xss，诱使点击xss链接，使其跳转到我们的钓鱼页面，然后钓鱼页面加载csrf poc。或者直接和之前一样，在用户名那里植入xss，然后管理员只要看日志就会触发xss的链接，可以将这个链接进行修改成csrf poc，进一步利用就像小皮面板那个一样要AI帮你生成poc对应的js语句，xss直接就可以触发。

Token验证-值删除&复用&留空

CSRF_token 对关键操作增加Token参数，token必须随机，每次都不一样，存储在cookie中，与验证码一样

image-20250815131413887

image-20250815131720209

当我换一个浏览器进行触发的时候：

image-20250815131904590

就会告诉我token验证失败

再次在浏览器中进行抓包：

image-20250815132310393

token值发生变化

那么这个东西到底有什么作用？试想一下，当你在实战情况下自己本地搭建源码，然后复现出来攻击的数据包，然后本地自己抓包获得到POC，然后诱使受害者进行触发， 但是因为有token的存在，每次访问都会发生变化， 你的token和他的token不一样当然也就执行不成功。

置空

image-20250815132831816

删除

image-20250815132851469

zblog—token复用

image-20250815133822436

这里需要知道受害者的Token才行。所以基本就是GG

漏洞修复

1
2
3
--对敏感信息的操作增加安全的token；
--对敏感信息的操作增加安全的验证码；
--对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。