What？点个链接，账户上的钱就没了？ 跨站伪造漏洞（CSRF) 浅析 靶场复现+及防御方法介绍

 

---

              全文约2000字，看完需要15分钟。       

---

 

        最近因为疫情隔离，每天的空闲时间比以往多了，正好有时间对自己反思，最近的观看量相比以前来说的确多了一点，也可以算上是自己一个微不足道的成就吧。 但说实话，我自己的水平也不咋地，发文章也仅是记录自己的学习过程与思考，如果对你们有哪怕一丁点帮助的话，我就很满足了。

 

目录

CSRF

pikachu靶场实战

准备阶段

攻击实施

回顾

CSRF的防御方式及优劣讨论

---

                                              

---

CSRF

简述：攻击者通过精心构造一个恶意URL，并诱导用户点击，以用户的身份执行各种操作。实现修改个人账号信息，密码，甚至是转账的操作。

产生条件：

1. 用户处于登陆状态
2. 用户点击了我们的恶意URL  （不点击啥事没有）

以上是在网站未做跨站伪造防护的条件下

而在实际上，只要代码和程序逻辑规范，可以完全避免跨站伪造漏洞。

老规矩先介绍原理：

估计小白看到这已经有点劝退了，哈哈。

没关系，我们看一个靶场实例了解黑客的攻击流程，带着这个思路去学习。

为方便使用GET类型的例子，实际上POST也差不多。（不多赘述2者差异）

pikachu靶场实战

准备阶段

在一个普通的界面我们选择登陆

选了一个默认账号allen 密码 123456

点击修改信息

 这里我们的本意是把所有信息修改为aaaa

 

 submit抓包

 

用burp自带工具 制作跨站伪造的html文件

 

 

我们把aaaa 全部转换为bbbb 修改完成后 点击生成按钮

 

之后再点击 Test in brower 这里自动会帮我们生成一个本地URL。也就是一个漏洞的HTML文档的地址。

 

 至此 准备阶段完成。 以上制造的html页面 就是我们的漏洞POC

攻击实施

这里开始登陆一个新账号 

Lucy

密码同样为123456

 

 我们直接访问我们在burpsuite copy的URL ，实际上点击这个URL，浏览器就会自动发送我们伪造的请求给服务器，造成跨站伪造漏洞。

 

也就是我们使用的Lucy 这个账号，会发送这样一个数据包给服务器，后面可想而知，信息肯定全部修改为 bbbb了。

具体操作

 通过下列操作模拟点击URL。 因为实际上，我们的URL必须放在公网服务器上才能被访问。所以我们只能在本地环境复现。

新建一个页面 把url放进去访问

 

 

 出现按钮 继续点击

 可以看到Lucy的信息 全变成b了。

 

回顾

        首先，我们使用Allen的账号，了解到了我们修改信息发送的数据包，根据这个数据包我们构造POC，这里利用burpsuite工具轻松制造出了一个本地HTML文件。

        其次，我们使用Lucy账号模拟被攻击的过程。登陆→点击恶意URL（最终访问了我们的HTML文件）→浏览器（Lucy处于登陆状态，所以以Lucy的身份）自动发送（HTML请求的内容）→最终信息被修改

1. 用户处于登陆状态
2. 用户点击了我们的恶意URL  （不点击啥事没有）

CSRF的防御方式及优劣讨论

• 验证码：比如每次发送请求，都向客户发送验证码，只有使用验证码经过验证才可以操作。（优势：非常安全 有效 劣势：影响用户体验：总不能修改个头像和ID都需要发验证码把！）
• Referer 检查 Referer 我们发送请求时，我们自己处于的界面，比如我们本次实验是新开了一个初始界面访问，那么Referer 应该就是我们的默认主页 （这里用burpsuite自带浏览器比较特殊，默认主页类似于www.baidu.com这类的）而正常的Referer应该是

http://127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get.php

（优势 方便，劣势：仍存在绕过的可能性 比如说在构造的URL中输入上述的伪造头，只不过实际情况下，我们的URL可能会带有一些COOIKE 等难以伪造的信息）

      

• token  服务器发送一个随机值，存放在Cooike中，这个随机值是攻击者无法伪造的，只在服务器与客户端保存，客户端每一次发送请求时，都会在表单（也就是攻击者恶意构造的URL中）放入token，服务器在接收到我们的请求时，会验证token是否与自己向客户端的token是否相同。并且在完成操作后向客户端新发一个token。（性价比最高，既安全又方便）

除非攻击者在构造的表单中能够伪造服务器发送给我们的Token，不然就在服务端验证不了，攻击就无法奏效。

这里要说明一些细节 可能大家对Cooike 以及Token 和验证的过程不了解：

1. token存在与Cooike中
2. 在csrf 攻击中，攻击者并不能获取我们的Cooike 只是利用了我们的登陆状态（在线）
3. 在向服务器发送请求的过程中，客户端将Token放入在表单（也就是这个URL名称中，导致这个URL我们无法伪造）

另外还要说明一点：csrf 通常也会与xss一起利用，形成XSRF，打个简单的比方：xss获取了Cooike信息的同时可以让受害者向服务端发送一些恶意请求（转账，点赞，抓包），而这个时候Token 也失去了作用。

最后，如果有空闲时间的话，可以更新一下相关内容

---

时间仓促，的确有一些写的不好和不全面的地方。如果老哥们有啥意见，欢迎评论或者私我。