csrf学习2，漏洞挖掘与防御

最新推荐文章于 2025-04-23 16:14:44 发布

jonhswei

最新推荐文章于 2025-04-23 16:14:44 发布

阅读量960

点赞数 13

文章标签：安全

本文链接：https://blog.csdn.net/jonhswei/article/details/147399199

版权

一、CSRF漏洞挖掘

1. CSRF漏洞原理

根本原因：当网站接口被第三方网站调用时，用户的cookie被直接利用
关键验证点：请求是否从系统自身的前端页面发起，而非其他域名下的请求
典型场景：转账、修改密码、修改手机号等敏感操作接口需要特别防护

2. 确定接口方法

核心标准：在第三方网站发起对目标接口的请求时，业务能执行成功即存在漏洞
敏感接口：主要关注转账、密码修改等高危操作接口，公开查询类接口无需拦截
验证方法：无需输入密码等二次验证的情况下调用成功即判定为漏洞

3. 操作方法

步骤1：通过正常操作获取目标接口地址和参数（如转账金额、账号等）
步骤2：构造第三方网页发起相同请求（如将表单保存为独立HTML文件）
步骤3：验证业务是否执行成功（如余额是否变化）
关键点：请求必须从非目标域名下发起才能验证跨站特性

4. 检测工具

1）Burp Suite

使用流程：
- 配置代理捕获目标请求
- 右键选择"Generate CSRF PoC"
- 保存生成的HTML文件并在非目标域名下访问
验证方法：通过余额变化等业务表现确认漏洞存在
特点：需要人工参与验证的半自动化工具

2）CSRFTester

工作原理：监听指定端口并分析请求
使用方式：需要手动配置代理和浏览器设置
输出结果：生成可用于验证的PoC代码

3）Bolt

特点：全自动化扫描工具
命令格式：bolt.py -u <目标URL>
输出标识："Insecure form(s) found"表示存在漏洞
优势：可批量扫描多个接口

4）云端产品

代表产品：腾讯云VSS、阿里云漏洞扫描等
检测能力：覆盖OWASP TOP 10漏洞包括CSRF
特点：商业付费服务，适合企业级应用
优势：无需本地部署，支持HTTPS扫描

二、知识小结

知识点	核心内容	考试重点/易混淆点	难度系数
CSRF漏洞原理	漏洞发生的根本原因是网站接口被第三方调用时Cookie被直接利用，关键在于请求是否从系统自身前端发起	域名验证逻辑（合法请求需来自自身域名）	⭐⭐
漏洞检测思路	在第三方网站发起敏感接口请求（如转账、修改密码），若业务执行成功则存在漏洞	敏感接口界定（公开API无需拦截，仅关注转账/密码修改等高危操作）	⭐⭐⭐
手动检测方法	1. 抓取目标接口请求参数 2. 在第三方网页构造相同请求 3. 验证业务是否被执行	请求伪造方式（需区分本地文件与跨站请求的等效性）	⭐⭐⭐⭐
工具辅助检测（半自动）	Burp Suite生成CSRF PoC：右键请求→Engagement Tools→Generate CSRF PoC→本地HTML触发验证	代理配置要点（默认监听8080端口，需关闭代理避免干扰）	⭐⭐⭐
全自动化工具	Bolt工具：批量扫描接口，输出不安全表单列表	云服务扫描（阿里云/腾讯云等付费漏洞扫描服务支持CSRF检测）	⭐⭐⭐⭐
防御措施	验证请求来源（Referer/Origin头）、添加CSRF Token、关键操作二次认证	误拦截风险（需排除公开API避免功能异常）	⭐⭐⭐

一、CSRF漏洞防御

1. 防御思路

1）防御思路概述

概述: CSRF漏洞防御主要有两个方向，一是识别请求来源，二是让前端页面与伪造请求变得不一样。

2）识别请求来源

识别请求来源: 通过判断请求是否来自自己的网站来区分合法与非法请求。

3）使用Referer字段

Referer字段: HTTP请求头中的一个字段，用于标识请求的来源页面。通过检查Referer字段，可以判断请求是否来自自己的网站。

4）Referer字段的作用

作用:
- 跟踪来源: 用于统计访问来源，如访问统计、广告效果跟踪等。
- 安全防御: 在CSRF防御中，通过检查Referer字段，可以拒绝来自第三方网站的请求。

5）服务端拦截与判断

服务端拦截与判断:
- 实现方式: 在后端代码中加入拦截器或过滤器，从HTTP请求头中获取Referer字段的值，并进行判断。
- 判断逻辑: 如果Referer字段的值不是自己的域名，则认为请求来自第三方网站，对于敏感接口，可以拒绝该请求，从而防止CSRF攻击。
示例: 通过在后端设置拦截器，检查每个请求的Referer字段，对于非自己域名的请求进行拦截和拒绝。

2. 案例分析

1）抓包尝试修改密码接口

靶场部署与登录
- 靶场部署: 我们之前已经讲过DVWA靶场的部署方法。
- 登录方式: 使用admin默认的password密码登录。
安全级别与漏洞场景
- 安全级别:
  - Low级别: 没有任何安全防护措施，可以随意调用。
  - 场景: 修改密码，只需输入两次新密码即可。
- 漏洞利用: 如果接口存在CSRF漏洞，攻击者可以在自己的网站植入代码，调用目标网站的修改密码接口。
Medium级别的安全措施
- 防护措施: 检查HTTP Referer字段是否包含当前域名（如localhost）。
- 源码分析:
  - 代码逻辑: 使用stripos($_SERVER['HTTP_REFERER'],$_SERVER['SERVER_NAME'])检查Referer字段。
  - 判断条件: 如果Referer不包含当前域名，则认为是非法请求。
- 绕过方法: HTTP请求包可以任意修改，包括Referer字段，可以将其修改为包含当前域名以骗过服务器。
High级别的安全措施
- 更高级别的防护: 使用Anti-CSRF Token进行校验。
- 源码分析:
  - Token校验: checkToken($_REQUEST['user_token'],$_SESSION['session_token'], 'index.php')。
  - Token生成: generateSessionToken()。
防御思路
- 区分请求来源:
  - 问题: 如何区分请求是来自自己的前端页面还是第三方网站？
  - 方法: 通过在请求中添加无法伪造的标识（如Token）来区分。
- 总结:
  - Referer字段: 可以作为基础校验，但不安全，因为可以伪造。
  - Token机制: 更安全的防护方式，通过Token校验请求的合法性。

3. 第二种方案

1）CSRF Token

CSRF Token（跨站请求伪造令牌）是一种用于保护Web应用程序免受CSRF攻击的安全机制。CSRF攻击是一种恶意攻击，攻击者利用已登录用户的身份，发起伪造的请求，从而执行未经授权的操作。

CSRF Token的工作原理：

令牌生成：当用户加载需要进行安全操作的网页（例如提交表单）时，服务器会生成一个唯一的CSRF令牌，并将其发送到客户端（通常保存在一个隐藏的表单字段或cookie中）。
令牌提交：当用户提交表单或发起更改服务器状态的请求（例如提交数据）时，CSRF令牌会随请求一起发送。
验证令牌：服务器会检查提交的CSRF令牌是否与之前发送的令牌一致。如果匹配，说明请求是合法的；如果不匹配，说明请求可能是伪造的，服务器会拒绝该请求。

CSRF Token使用示例：

服务器在渲染表单时，发送一个CSRF令牌：

<form method="POST" action="/submit">
    <input type="hidden" name="csrf_token" value="unique_token_value">
    <!-- 其他表单字段 -->
    <button type="submit">提交</button>
</form>

当表单提交时，服务器会检查csrf_token字段的值是否正确。

CSRF Token的作用：

防止攻击：CSRF令牌防止恶意请求伪装成用户请求，确保请求是真正由用户发起的。
安全验证：令牌的验证过程确保请求是由与页面交互的合法用户发起的，而不是恶意网站伪造的请求。
CSRF Token步骤一
- 步骤一: 用户使用用户名密码登录，服务端下发一个随机的token字段给客户端，并且服务端把这个字段保存在session中。
- 实现方式: 使用session_start()开启会话，检查$_SESSION['token']是否存在，若不存在则生成一个新的token并保存到session中。
CSRF Token步骤二
- 步骤二: 客户端把这个token保存起来，放到隐藏字段。
- 保存位置: 最好不要放到cookie里面，因为cookie是明文的，容易被窃取。建议放到隐藏字段中。
CSRF Token步骤三
- 步骤三: 用户在登陆状态下，在之后访问的时候，都要携带这个token字段。
- 携带方式: 在表单中添加一个隐藏的input字段，字段名为user_token，值为服务端下发的token。
CSRF Token步骤四
- 步骤四: 服务端从session中拿出token值进行对比，如果一致，说明请求合法。
- 对比方式: 使用hash_equals()函数比较$_SESSION['token']和$_POST['token']，若一致则执行业务逻辑，否则返回错误。
CSRF Token步骤五
- 步骤五: 用户退出，session销毁，token失效。
- 失效方式: 用户退出时销毁session，使token失效，防止token被滥用。

2）问题

问题: 即使使用了CSRF Token，是否就100%安全了？
答案: 不一定。如果网站存在其他漏洞（如XSS漏洞），攻击者仍可能利用这些漏洞获取到user token，从而进行CSRF攻击。因此，CSRF Token并不是终极的解决方案，需要结合其他安全措施共同防护。

4. 应用案例

1）Reflected Cross Site Scripting (XSS)案例

XSS攻击: Reflected XSS是一种跨站脚本攻击，攻击者通过注入恶意脚本，使用户在访问特定页面时执行该脚本，从而窃取信息或进行其他恶意操作。
安全级别: 提到某个安全级别对于任何攻击方式来说都是安全的，但具体级别未详细说明。

2）Cross Site Request Forgery (CSRF)案例与二次验证

CSRF攻击: 攻击者诱导用户访问恶意页面，利用用户已登录的身份，向目标网站发送未经授权的请求，如修改密码。
二次验证: 在进行敏感操作（如修改密码）时，要求用户再次输入当前密码，以验证身份。这是一种增强安全性的措施。

3）二次验证的其他方法

验证码: 通过识别图片中的特定元素或按特定顺序点击汉字等方式，增加自动化攻击的难度。
滑动解锁: 相对安全的验证方式，但仍非100%安全。
短信验证: 在修改绑定手机号等场景中，要求旧手机号接收短信验证码，以确认身份。

4）敏感操作与二次验证

敏感操作: 如删除网盘文件、清空回收站等，这些操作一旦执行，可能无法恢复。
二次验证的必要性: 对于这类敏感操作，必须确保是账号拥有者本人在操作，可以通过扫码、人脸识别加活体检测等方式进行二次验证。

5）谷歌recapture人机验证机制

recapture机制: 谷歌的一种人机验证机制，当系统检测到异常操作（如爬虫或代码操作）时，会弹出人机验证界面，要求用户完成特定任务（如找出图片中的特定元素）。
目的: 通过增加自动化攻击的难度，保护网站免受恶意攻击。
应用场景: 适用于操作比较奇怪的IP，或尝试修改多个账号密码等异常行为。

5. 验证码

1）浏览器对验证码的影响

火狐浏览器与验证码: 使用火狐浏览器时，验证码功能正常。
谷歌浏览器与验证码: 在谷歌浏览器中，尝试进行相同操作（如登录、提交等），但验证码可能不奏效。演示中，尽管进行了提交操作，但余额并未减少。
原因分析: 可能是由于浏览器之间的兼容性差异或安全设置不同导致的。谷歌浏览器可能对某些验证码的实现方式有特定的处理机制，导致验证码功能失效。

2）验证码的重要性与类型

验证码的重要性: 验证码是一种安全措施，用于防止非法攻击，如暴力破解、跨站脚本攻击（XSS）等。它要求用户输入特定的字符或完成特定的操作，以证明其是人类而非自动化脚本。
验证码的类型: 验证码有多种类型，如图片验证码（如示例中的“米饭12
⊗\otimes⊗
”）、人脸识别验证码（如ppt_content中的“人脸识别认证”）、IP验证码（如“reCAPTCHA(IP验证)”）等。
reCAPTCHA(IP验证)说明: 这是一种通过选择包含特定元素（如火警栓）的图片来完成的验证码。它结合了图片识别和人工智能技术，旨在提高验证的准确性和用户体验。

3）跨站脚本攻击（XSS）与验证码

XSS攻击: 跨站脚本攻击是一种常见的网络安全威胁，攻击者通过在网页中注入恶意脚本，试图窃取用户的敏感信息或执行其他恶意操作。
验证码与XSS防御: 验证码可以作为防御XSS攻击的一种手段。通过要求用户输入验证码，可以确保提交请求的是人类用户而非自动化脚本，从而降低XSS攻击的风险。
DVWA中的XSS演示: 在DVWA（Damn Vulnerable Web Application）中，有一个关于反射型跨站脚本攻击（Reflected XSS）的演示。通过输入特定的恶意脚本，可以在用户的浏览器中执行该脚本，从而窃取信息或执行其他恶意操作。而验证码的引入，可以有效防止这种攻击的发生。

6. 浏览器Referrer Policy策略

1）Referrer Policy简介

Referrer Policy定义: Referrer Policy是浏览器的一个安全策略，用于控制页面在请求资源时是否携带referrer信息。
作用: 控制页面在跨站请求时是否带上来源信息，有助于防止CSRF等安全威胁。

2）strict-origin-when-cross-origin策略

策略描述: 当设置为strict-origin-when-cross-origin时，浏览器在跨域请求时，只会发送origin部分，不会发送完整的URL路径和参数。
效果: 若请求为跨站请求且只携带域名，无其他参数，增强安全性。

3）Referrer Policy对浏览器行为的影响

跨站请求行为: 在strict-origin-when-cross-origin策略下，若从一个域名访问另一个域名的接口，浏览器只会发送域名，不会发送路径和参数。
安全意义: 此策略有助于防止CSRF攻击，因为攻击者无法获取完整的请求URL和参数。

4）Referrer Policy的防御作用

防御CSRF: 通过设置严格的Referrer Policy，可以有效防止跨站请求伪造(CSRF)攻击。
实际应用: 在金融、网银等敏感领域，建议采用严格的Referrer Policy以增强安全性。

5）Referrer Policy配置与效果

配置方法: 在HTTP响应头中设置Referrer-Policy字段，如strict-origin-when-cross-origin。
效果展示: 配置后，浏览器在跨域请求时只会携带域名，提高安全性，但可能影响部分功能的正常使用（如需要完整URL的路径和参数的功能）。

7. 浏览器保护措施

1）浏览器的基本安全保护措施

基本安全保护: 一些浏览器具有基本的安全保护措施，如防止CSR漏洞等。
实例说明: 火狐浏览器在此课程中未做校验，以便讲解CSR漏洞；但其他浏览器可能已有此类保护。

2）网站开发者的用户保护措施

用户保护: 网站开发者应采取多种措施来保护用户，如二次验证、人脸识别等。
实例说明: 通过reCAPTCHA(IP验证)等方式进行安全校验，增加非法攻击的难度。

3）用户自身的安全注意事项

用户注意: 如果网站缺乏安全措施，用户应自行注意并采取措施保护自身安全。
提醒: 用户在使用网站时，应留意网站的安全性，避免在不安全的网站上进行敏感操作。
不要随便去访问一些不安全的网站，也不要去随便点开别人在QQ，微信或者QQ邮箱里面发给你的一些链接，因为。你可能真的在不知不觉中一点开这个链接csr的攻击就发生了啊，顺便呢

二、知识小结

知识点	核心内容	考试重点/易混淆点	难度系数
CSR漏洞修复与防御	识别请求来源与添加特殊参数	识别请求来源的方法与实现	中
- 识别请求来源	利用HTTP头字段referral	referral字段的作用与伪造风险	中
- 添加特殊参数	使用token进行身份验证	token的生成、存储与验证流程	中
浏览器安全策略	谷歌浏览器的referral policy	不同浏览器对跨站请求的处理差异	低
- referral policy	strict origin when cross origin策略	该策略对跨站请求的影响	低
二次验证方法	验证码、短信验证、人脸识别等	二次验证的应用场景与实现方式	中
- 验证码	图片验证、滑动解锁等	验证码的破解难度与安全性	中
- 短信验证	修改绑定手机号时的短信验证	短信验证的流程与安全性	中
- 人脸识别	扫码验证、活体检测等	人脸识别的技术原理与应用	中
用户安全建议	避免访问不安全网站与点击不明链接	用户行为对安全的影响	低
- 不安全网站	可能存在的安全风险	如何识别与避免访问不安全网站	低
- 不明链接	链接中的潜在威胁	如何处理不明链接以确保安全	低