目录

前言

漏洞介绍

漏洞原理

产生条件

产生的危害

靶场练习

post 请求csrf案例

防御措施

验证请求来源

设置 SameSite 属性

双重提交 Cookie

结语

---

前言

在网络安全领域，各类漏洞层出不穷，时刻威胁着用户的隐私与数据安全。跨站请求伪造（Cross - Site Request Forgery，简称 CSRF）漏洞便是其中较为隐蔽且危害较大的一种。它如同隐藏在暗处的 “小偷”，悄无声息地窃取用户权限，执行恶意操作。了解 CSRF 漏洞，无论是对 Web 开发者加固应用安全，还是对普通用户提升安全防范意识，都有着重要意义。

漏洞介绍

CSRF 漏洞，简单来说，是指攻击者诱导受害者进入一个恶意链接，利用受害者在已登录的目标网站上的身份验证信息，在受害者不知情的情况下，以受害者的名义在目标网站上执行非本意的操作。与跨站脚本（XSS）漏洞不同，CSRF 漏洞主要利用的是网站对用户浏览器的信任，而非直接攻击用户浏览器。这种漏洞广泛存在于各类 Web 应用中，只要应用依赖用户的身份验证来执行敏感操作，就有可能受到 CSRF 攻击的威胁。

漏洞原理

1. 用户登录与身份验证：用户在目标网站进行登录，网站通过 Cookie 或 Token 等方式对用户进行身份验证，并在后续请求中识别用户身份。例如，用户登录银行网站后，银行网站会为用户生成一个包含身份信息的 Cookie，用户后续的转账、查询等操作，网站都会根据这个 Cookie 来确认用户身份。
2. 攻击者构造恶意链接：攻击者精心构造一个包含恶意操作的链接，比如转账到攻击者账户的链接。这个链接的请求地址是目标网站的合法操作地址，但是参数被攻击者篡改，包含了恶意指令。
3. 诱导受害者访问：攻击者通过各种手段，如发送恶意邮件、在社交平台发布诱人的消息等，诱导受害者点击这个恶意链接。当受害者点击链接时，由于受害者的浏览器中保存着目标网站的身份验证信息（如 Cookie），浏览器会自动带上这些信息向目标网站发送请求。
4. 目标网站执行恶意操作：目标网站接收到请求后，根据附带的身份验证信息，认为请求来自合法用户，从而执行了链接中的恶意操作，如转账、修改密码等，而受害者对此毫不知情。

产生条件

1. 目标网站存在敏感操作：网站提供了如转账、修改密码、删除重要数据等敏感操作，这些操作仅应在用户主动发起且确认的情况下执行。
2. 身份验证信息存储方式不当：网站依赖 Cookie 或其他简单的身份验证机制，且这些验证信息在用户浏览器中存储，容易被攻击者利用。例如，Cookie 没有设置 HttpOnly 属性，使得攻击者可以通过 JavaScript 读取 Cookie 内容，进一步利用。
3. 缺乏有效的防御机制：网站没有对请求来源进行严格验证，无法识别出请求是否来自合法用户的主动操作，还是被攻击者诱导的恶意请求。

产生的危害

1. 经济损失：在金融类网站中，攻击者利用 CSRF 漏洞进行转账操作，直接导致用户的资金被盗取，给用户带来严重的经济损失。
2. 隐私泄露：攻击者可以修改用户的个人信息，如在社交网站上修改用户的隐私设置，将原本私密的信息公开，造成用户隐私泄露。
3. 账号被盗用：通过修改用户密码，攻击者可以轻松登录用户账号，进一步控制用户的账户，发布恶意信息，甚至利用用户的社交关系进行诈骗等活动。

靶场练习

1. 搭建靶场环境：使用开源的 Web 安全靶场，在这里使用的是DVWA（Damn Vulnerable Web Application）。在虚拟机环境中部署 DVWA，设置好相关的数据库和配置文件。
2. 选择 CSRF 漏洞模块：进入 DVWA 的 CSRF 漏洞测试模块，将安全级别设置为 “Low”，这个级别下的漏洞比较容易复现。
3. 构造恶意链接：查看low模式下的源代码是否有进行过滤，可以查看没有进行过滤校验在该模块中，有一个修改用户密码的功能。攻击者可以通过抓包工具（如 Burp Suite）获取正常修改密码的请求包，然后修改其中的密码参数，构造出一个恶意链接。正常的修改密码请求是，攻击者将其修改为http://10.0.0.100:90/DVwa-master/vulnerabilities/csrf/?password_new=123456333&password_conf=123456333&Change=Change#。
4. 诱导受害者访问：假设受害者已经登录了 DVWA 且浏览器中保存了登录的 Cookie。攻击者将构造好的恶意链接发送给受害者，当受害者点击链接时，浏览器会自动带上 Cookie 向 DVWA 发送请求，从而实现密码修改，完成 CSRF 攻击的复现。
5. 防御措施验证：将 DVWA 的安全级别提升到 “Medium” 或 “High”，再次尝试上述攻击。在 “Medium” 级别，网站可能会增加一些简单的防御机制，如在请求中增加一个随机的 Token，验证 Token 的合法性。攻击者会发现攻击无法成功，从而理解防御 CSRF 漏洞的原理和方法。

post 请求csrf案例

1. 登录凡诺后台修改密码：
   操作描述：攻击者首先正常登录凡诺后台系统，进入修改密码的功能页面。在这个页面中，攻击者会输入新密码并提交修改请求，这一步的目的是触发系统的修改密码操作，以便后续利用这个操作来构造 CSRF 攻击。在这里我修改的密码是1234567。
   重要性：通过这一步，攻击者可以熟悉修改密码的流程和页面布局，同时为后续抓包获取必要的请求信息做准备。

2. 使用 Burp Suite 抓包

   抓包工具介绍：Burp Suite 是一款广泛使用的 Web 应用程序安全测试工具，它可以拦截、修改和分析 HTTP 请求和响应。攻击者利用 Burp Suite 的抓包功能，捕获在凡诺后台修改密码时浏览器发送的请求。
   请求类型与关键信息：
   没有 Token 值：Token 是一种用于防止 CSRF 攻击的机制，通常是服务器生成的一个随机字符串，会在每次请求中附带。如果请求中没有 Token 值，说明该系统在修改密码这个功能上可能没有实现有效的 CSRF 防护，这为攻击者提供了可乘之机。
   POST 请求：抓包结果显示修改密码的请求是一个 POST 请求。POST 请求通常用于向服务器提交数据，在修改密码的场景中，新密码等重要信息会通过 POST 请求发送到服务器。

3. 使用 Burp Suite 生成 POC（Proof of Concept，概念验证）

   POC 生成过程：
   1. 通过分析生成的 POC 代码，可以看到请求的详细信息，包括请求的 URL、请求方法（POST）、请求参数（如用户名、新密码等）。
      在 Burp Suite 中，攻击者可以利用抓包得到的请求信息，使用其内置的功能生成一个 POC。这个 POC 本质上是一段可以模拟用户修改密码请求的代码，通常是一段 JavaScript 代码。
      
      将修改后的 JavaScript 代码复制到一个新的 HTML 文件中。HTML 文件可以在浏览器中打开，当浏览器加载这个 HTML 文件时，其中的 JavaScript 代码会自动执行，向凡诺后台服务器发送修改密码的请求。
   • 修改代码并创建 HTML 文件：这里将1234567的密码修改为12345678，将代码放在单独的文件中
   • 废弃 Burp Suite 数据包：在完成 HTML 文件的创建后，攻击者不再需要之前在 Burp Suite 中捕获的原始数据包，因此可以将其废弃。

4. 诱导被攻击者打开 HTML 文件

   • 攻击原理：当被攻击者在已经登录凡诺后台的状态下打开攻击者构造的 HTML 文件时，浏览器会执行其中的 JavaScript 代码，向凡诺后台服务器发送修改密码的请求。由于被攻击者的浏览器中保存着登录凡诺后台的会话信息（如 Cookie），服务器会认为这个请求是由合法用户发起的，从而执行修改密码的操作。在这里我们在本机环境中进行演示。
   • 攻击成功标志：如果被攻击者成功打开了 HTML 文件，并且服务器接受了修改密码的请求，那么攻击就成功了。攻击者可以通过检查凡诺后台的密码是否被修改来确认攻击结果。
   • 此时输入1234567发现密码错误，已经更改为12345678

防御措施

1. 验证请求来源

• Referer 验证：服务器可以通过检查请求头中的 Referer 字段来判断请求的来源。如果 Referer 字段的值不符合预期，说明请求可能来自恶意网站，可以拒绝该请求。但需要注意的是，Referer 字段可以被篡改，因此这种方法并不是绝对安全的。
• 同源策略：现代浏览器遵循同源策略，只有来自同一源（协议、域名和端口都相同）的页面才能直接访问另一个页面的资源。服务器可以利用这一特性，确保请求来自合法的源。

1. 使用 CSRF Token

• 生成 Token：服务器在用户访问包含敏感操作的页面时，生成一个随机且唯一的 CSRF Token，并将其存储在服务器端（如会话中），同时将 Token 嵌入到页面中（如隐藏表单字段或请求头）。
• 验证 Token：当用户提交请求时，客户端需要将 Token 一并发送给服务器。服务器验证客户端提交的 Token 与服务器端存储的 Token 是否一致，如果一致则认为请求合法，否则拒绝请求。

1. 设置 SameSite 属性

SameSite 是 Cookie 的一个属性，用于控制 Cookie 在跨站请求中的传递。可以将 Cookie 的 SameSite 属性设置为 “Strict” 或 “Lax”，以限制 Cookie 只在同源请求或同站请求中传递，从而减少 CSRF 攻击的风险。

双重提交 Cookie

服务器在用户访问页面时，生成一个随机的 Token 并将其存储在 Cookie 中，同时将该 Token 嵌入到页面的表单字段或请求头中。当用户提交请求时，服务器会比较 Cookie 中的 Token 和请求中携带的 Token 是否一致，如果一致则认为请求合法。

结语

CSRF 漏洞虽然隐蔽，但只要开发者和用户提高安全意识，采取有效的防范措施，就能大大降低其带来的风险。对于开发者来说，要在代码层面增加对请求来源的验证，使用 Token 等技术防止恶意请求。对于用户而言，要谨慎点击不明链接，尤其是在已登录重要网站的情况下。网络安全是一场持久战，需要我们不断学习和实践，共同守护网络空间的安全。