深入剖析 CSRF 漏洞：原理、危害案例与防护

前言

漏洞介绍

漏洞原理

产生条件

产生的危害

靶场练习

[post 请求csrf案例](#post 请求csrf案例)

防御措施

验证请求来源

[设置 SameSite 属性](#设置 SameSite 属性)

[双重提交 Cookie](#双重提交 Cookie)

结语

前言

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

漏洞介绍

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

漏洞原理

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

产生条件

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

产生的危害

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

靶场练习

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

post 请求csrf案例

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

抓包工具介绍 ：Burp Suite 是一款广泛使用的 Web 应用程序安全测试工具，它可以拦截、修改和分析 HTTP 请求和响应。攻击者利用 Burp Suite 的抓包功能，捕获在凡诺后台修改密码时浏览器发送的请求。
请求类型与关键信息 ：
没有 Token 值 ：Token 是一种用于防止 CSRF 攻击的机制，通常是服务器生成的一个随机字符串，会在每次请求中附带。如果请求中没有 Token 值，说明该系统在修改密码这个功能上可能没有实现有效的 CSRF 防护，这为攻击者提供了可乘之机。
POST 请求 ：抓包结果显示修改密码的请求是一个 POST 请求。POST 请求通常用于向服务器提交数据，在修改密码的场景中，新密码等重要信息会通过 POST 请求发送到服务器。
使用 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 中捕获的原始数据包，因此可以将其废弃。
诱导被攻击者打开 HTML 文件
- 攻击原理：当被攻击者在已经登录凡诺后台的状态下打开攻击者构造的 HTML 文件时，浏览器会执行其中的 JavaScript 代码，向凡诺后台服务器发送修改密码的请求。由于被攻击者的浏览器中保存着登录凡诺后台的会话信息（如 Cookie），服务器会认为这个请求是由合法用户发起的，从而执行修改密码的操作。在这里我们在本机环境中进行演示。
- 攻击成功标志 ：如果被攻击者成功打开了 HTML 文件，并且服务器接受了修改密码的请求，那么攻击就成功了。攻击者可以通过检查凡诺后台的密码是否被修改来确认攻击结果。
- 此时输入1234567发现密码错误，已经更改为12345678

防御措施

验证请求来源

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

使用 CSRF Token

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

设置 SameSite 属性

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

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

结语

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