1. 简介
逻辑漏洞是指由于程序逻辑不严导致一些逻辑分支处理错误造成的漏洞。
在实际开发中,因为开发者水平不一没有安全意识,而且业务发展迅速内部测试没有及时到位,所以常常会出现类似的漏洞。
2. 安装逻辑
- 查看能否绕过判定重新安装
- 查看能否利用安装文件获取信息
- 看能否利用更新功能获取信息
3. 交易
3.1. 购买
在渗透测试中,与“购买/支付/订单”相关的逻辑漏洞是最常见且危害极大的业务安全问题之一。至今实测中,这类漏洞在电商、小程序商城、会员系统、虚拟商品充值系统中仍高发。
会出现的类型有:
- 修改支付的价格
- 修改支付的状态
- 修改购买数量为负数
- 修改金额为负数
- 重放成功的请求
- 并发数据库锁处理不当
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固方向) |
|---|---|---|---|
| 修改支付价格 | 前端价格可控,后端未重新计算或校验 | 1元买千元商品 | 后端从数据库/缓存重新读取商品单价并计算总额 |
| 修改支付状态 | 支付回调通知(notify_url)缺少签名校验或可伪造 | 未支付却标记为已支付 | 回调必须严格签名校验 + 幂等性 + 查询第三方订单状态 |
| 修改购买数量为负数 | 数量字段可传负值,后端未校验或校验不严 | 负数购买 → 退款正数金额(赚差价) | 数量必须 >0 且 ≤ 库存,后端强制校验 |
| 修改金额为负数 | 总金额、单价字段可传负值 | 支付负金额 → 相当于平台给你钱 | 所有金额字段后端重新计算并校验 ≥0 |
| 重放成功的请求 | 下单/支付成功接口缺少防重放机制(无nonce、timestamp、token一次性验证) | 重复下单/重复支付成功 | 引入一次性token、订单号幂等校验、时间戳+nonce |
| 并发数据库锁处理不当 | 高并发下单秒杀/库存扣减未加锁或使用乐观锁失败未回滚 | 超卖、库存变为负数 | 使用数据库悲观锁/乐观锁+重试,或Redis分布式锁 |
3.2. 业务风控
在渗透测试中,业务风控类逻辑漏洞(尤其是刷优惠券和套现)是2025年高危业务安全问题中最常见、最具经济危害的一类。
会出现的类型有:
- 刷优惠券
- 套现
3.2.1. 刷优惠券类逻辑漏洞(常见于电商、会员、营销活动)
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固方向) |
|---|---|---|---|
| 重复领取优惠券 | 领取接口无防重机制(无用户+活动+设备唯一标识) | 一人领取N张券,无限薅羊毛 | 数据库唯一约束(user_id + coupon_id + activity_id)+ Redis幂等锁 |
| 无限制领取 | 领取次数未校验或校验逻辑放在前端/可绕过 | 无限刷券 | 后端严格校验剩余领取次数,写死上限 |
| 跨用户领取 | 优惠券ID可控,未校验归属用户 | 拿别人专属券 | 领取时校验user_id与token对应一致 |
| 活动结束后仍可领取 | 活动结束时间校验不严或未校验 | 过期活动仍薅 | 后端查询活动状态(start_time ≤ now ≤ end_time) |
| 多设备/多账号薅 | 无设备指纹/IP/行为风控,同一用户多设备可重复领 | 批量刷券 | 引入设备指纹(Canvas/WebGL)+ IP/行为限流 |
3.2.2. 套现类逻辑漏洞(常见于虚拟商品、充值、提现、积分兑换)
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固方向) |
|---|---|---|---|
| 负金额/负数量套现 | 支付/兑换接口允许负数金额或数量 | 平台给你钱 | 所有金额/数量字段后端校验 ≥0 |
| 退款后仍保留商品/积分 | 退款回调未同步扣除商品/积分 | 退款后仍可使用商品 | 退款时同步扣除商品/积分 + 幂等性校验 |
| 循环套现 | 充值 → 消费 → 退款 → 再充值 → 无限循环 | 资金池无限放大 | 充值/消费/退款流水记录 + 限频 + 风控阈值 |
| 积分/余额刷取 | 积分兑换接口未校验库存或可负数 | 无限刷积分/余额 | 积分兑换需校验库存、余额、次数上限 |
| 风控绕过(弱校验) | 风控接口返回可控(如risk_score=0)或未校验 | 绕过所有风控 | 风控结果必须后端校验,禁止前端可控 |
4. 账户
4.1. 注册
- 覆盖注册
- 尝试重复用户名
- 注册遍历猜解已有账号
在渗透测试中,账户注册相关的逻辑漏洞是业务安全中最基础却又极易被忽视的一类。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固) |
|---|---|---|---|
| 允许重复注册同一用户名 | 注册接口未对用户名/手机号/邮箱做唯一性校验 | 后注册用户覆盖前用户账户,导致账号劫持 | 数据库用户名/手机号/邮箱字段加唯一索引,后端严格返回“已存在” |
| 注册覆盖(Overwrite) | 重复注册时直接更新已有用户记录(密码、手机号、邮箱等被新值替换) | 任意账号密码重置、手机号劫持 | 重复注册直接拒绝,不允许任何字段更新 |
| 弱用户名枚举/遍历猜解 | 注册接口返回信息差异化(如“用户名已存在”“手机号已注册”“邮箱已注册”) | 可批量枚举系统中已有账号,结合社工进一步攻击 | 返回统一提示(如“账号已被使用”),禁止差异化返回 |
| 无验证码/弱验证码 | 注册无图形/短信验证码,或验证码可暴力猜解/重放 | 批量注册马甲账号,用于刷奖、刷单、刷券 | 必须强制短信/邮箱验证码 + 限频 + 图形验证码辅助 |
| 手机号/邮箱未唯一校验 | 同一手机号/邮箱可被多个账号绑定 | 一个手机号控制多个账号 | 手机号/邮箱字段加唯一约束,后端强制校验 |
| 注册送礼滥用 | 注册成功即送优惠券/余额/积分,无风控限制 | 批量注册无限薅注册礼包 | 注册礼包绑定设备指纹/IP/行为风控,设置上限 |
| 邀请码无限使用 | 邀请码无使用次数限制,或老用户可自邀 | 无限刷邀请奖励 | 邀请码设置一次有效,或限制邀请次数 |
4.2. 密码
- 密码未使用哈希算法保存
- 没有验证用户设置密码的强度
在渗透测试中,密码处理相关的逻辑漏洞属于账户安全的核心问题。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固) |
|---|---|---|---|
| 密码未使用哈希算法保存(明文/可逆加密) | 数据库被脱库后密码直接可读,或通过逻辑漏洞(如备份文件、日志)泄露密码 | 全量用户密码泄露,撞库/社工风险极高 | 必须使用不可逆强哈希:bcrypt、scrypt、Argon2(推荐Argon2id)+ 随机盐 |
| 密码使用弱哈希算法(MD5/SHA1) | 脱库后密码字段为32/40位固定长度,无盐或盐明文存储 | 彩虹表/GPU暴力破解秒解 | 强制升级至Argon2/bcrypt,旧数据迁移时重新哈希 |
| 哈希无盐或盐复用 | 同一密码所有用户哈希值相同,或盐字段可预测 | 批量破解效率大幅提升 | 每用户独立生成高熵随机盐(≥16字节),盐与哈希一同存储 |
| 没有验证密码强度 | 注册/改密接口允许弱密码(123456、aaaaa、姓名+生日等) | 用户普遍弱口令,易被暴力破解或猜解 | 后端强制复杂度:≥12位 + 大小写 + 数字 + 特殊字符,不能包含用户名/手机号等 |
| 密码传输明文 | 登录接口使用HTTP或明文POST密码,未强制HTTPS | 中间人嗅探获取密码 | 全站强制HTTPS + HSTS,密码字段额外可客户端哈希(不推荐替代后端哈希) |
4.3. 邮箱用户名
- 前后空格
- 大小写变换
在渗透测试中,邮箱用户名相关的逻辑漏洞主要集中在注册、登录、密码重置等环节对邮箱地址的规范化处理不严,导致绕过唯一性校验或账号控制。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固) |
|---|---|---|---|
| 前后空格不敏感 | 注册/登录时邮箱前后添加空格(如" user@example.com ")被系统自动trim或忽略 | 绕过唯一性校验,重复注册或劫持已有账号 | 后端存储和校验前必须严格 trim(),但唯一性校验使用标准化后邮箱(trim + toLowerCase) |
| 大小写不敏感绕过 | 邮箱用户名部分(@前)大小写混用(如 Test@Example.com 与 test@example.com)被视为相同 | 绕过唯一性校验,重复注册或账号冲突 | 存储和唯一性校验时将邮箱用户名部分强制 toLowerCase()(域名部分保持原样,RFC允许区分但实际几乎不区分) |
| 空格+大小写组合 | 同时使用前后空格 + 大小写变换(如" Test@Example.com ") | 更高成功率绕过弱校验系统 | 标准化流程:trim() → username部分 toLowerCase() → 再校验唯一性 |
| 点号变形(Gmail特有) | Gmail用户忽略点号(te.st@example.com ≡ test@example.com) | 仅Gmail有效,但若系统未处理可导致重复注册 | 若支持Gmail,建议统一去除点号后存储,或提示用户点号等价 |
| 登录/重置环节不一致 | 注册时严格规范,但登录/找回密码时未规范,导致可用变形登录原账号 | 账号被“伪劫持”,攻击者可用变形版本控制原账号 | 所有环节(注册、登录、重置、绑定)必须使用同一套标准化规则 |
4.4. Cookie
- 包含敏感信息
- 未验证合法性可伪造
在渗透测试中,Cookie相关的逻辑漏洞是业务安全中极易被忽视却危害极大的类型。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固) |
|---|---|---|---|
| Cookie包含敏感信息(明文) | Cookie中直接存放user_id、username、role、balance、手机号、邮箱等敏感数据 | 被窃取后直接接管账号或泄露隐私 | 禁止在Cookie存放任何明文敏感信息;必要信息必须加密+签名 |
| Cookie未加密 | 敏感信息Base64编码或简单可逆加密(如异或、ROT13) | 解码后直接获取敏感数据 | 使用AES-GCM等强加密 + HMAC签名,密钥后端硬编码或KMS管理 |
| Cookie未签名/弱签名 | Cookie无签名或使用弱算法(MD5、SHA1、无盐) | 可任意伪造管理员/高权限Cookie | 必须使用强签名(如HMAC-SHA256 + 密钥),后端严格验证签名 |
| Cookie可预测/编码伪造 | Cookie值为可预测序列(如user_id递增、时间戳+MD5)或仅Base64无签名 | 横向越权,遍历其他用户账号 | 使用高熵随机值(如UUID)+加密+签名,禁止可预测结构 |
| Cookie作用域/路径过宽 | Domain/Path设置过大(如Domain=.example.com,Path=/) | 子域劫持或全站Cookie窃取 | 严格限制Domain(精确到当前子域)和Path(精确到应用路径) |
| 缺少HttpOnly/Secure标志 | Cookie未设置HttpOnly(JS可读)或Secure(HTTP可传) | XSS窃取Cookie或中间人嗅探 | 所有会话Cookie必须强制 HttpOnly + Secure + SameSite=Strict/Lax |
| Cookie未及时失效 | 退出登录后Cookie仍有效,或长期有效期 | 退出后仍可使用旧Cookie登录 | 退出时后端主动失效(删除session + 设置Cookie Max-Age=0) |
4.5. 手机号用户名
- 前后空格
- +86
在渗透测试中,“手机号作为用户名”相关的逻辑漏洞主要出现在注册、登录、密码重置、短信验证码等环节对手机号格式的规范化处理不严,导致绕过唯一性校验或账号劫持。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| 前后空格不敏感 | 注册/登录时手机号前后添加空格 (如" 13812345678 ")被系统自动trim或忽略 | 绕过唯一性校验,可重复注册或覆盖已有账号 | 后端存储和校验前必须严格 trim(),唯一性校验使用标准化后手机号 |
| +86前缀变体绕过 | 系统只接受纯11位手机号,但接受带+86、86、0086等前缀的号码被自动去除或视为相同 | 绕过唯一性校验,重复注册或账号劫持 | 标准化流程:去除所有非数字字符 → 若长度>11取后11位 → 若以1开头保留,否则拒绝 |
| 空格 + +86组合 | 同时使用前后空格 + +86前缀(如" +86 13812345678 ") | 更高成功率绕过弱校验系统 | 统一正则清理:只保留连续11位数字,且必须以1开头 |
| 其他国家区号伪造 | 输入其他区号(如+0013812345678、+85213812345678)若系统仅去除+号未校验 | 伪造绕过或导致异常账号 | 严格限制只接受+86或纯11位中国大陆手机号 |
| 登录/重置环节不一致 | 注册时严格去+86,但登录或短信验证码重置时接受带+86,导致可用变体控制原账号 | 账号被“伪劫持”,攻击者可用变体版本重置密码 | 所有环节(注册、登录、重置、验证码发送)必须使用同一套标准化规则 |
4.6. 登录
- 撞库
- 设置异地登录检查等机制
- 账号劫持
- 恶意尝试帐号密码锁死账户
- 需要设置锁定机制与解锁机制
- 不安全的传输信道
- 登录凭证存储在不安全的位置
在渗透测试中,登录环节的逻辑漏洞是账户安全的核心战场。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| 撞库攻击(Credential Stuffing) | 使用外部泄露的用户名+密码组合批量尝试登录 | 大量用户账号被批量接管 | 失败次数阈值锁定 + 异地/异常行为触发二次验证 + IP/账号限频 |
| 恶意尝试导致账户永久锁死 | 暴力破解多次失败后账号被永久锁定,无解锁机制或解锁流程复杂 | 拒绝服务攻击(DoS),合法用户无法登录 | 设置临时锁定(5-30分钟)+ 自动解锁或自助解锁(短信/邮箱+二次验证) |
| 无账号锁定/弱锁定机制 | 登录失败次数无上限,或锁定时间极短(如10秒) | 暴力破解/撞库成功率极高 | 失败5次锁定30分钟,失败10次锁定24小时 + 异常IP全局限流 |
| 账号劫持(Session/Cookie劫持) | SessionID/Cookie可预测、未绑定IP/设备,或传输明文 | 攻击者接管合法用户会话 | Session绑定IP段+设备指纹 + 异地登录强制重新认证 + HttpOnly/Secure/SameSite |
| 异地登录检查机制缺失/弱实现 | 无异地登录二次验证,或仅前端弹窗提示 | 撞库成功后直接接管,无需额外验证 | 异地/新设备登录强制短信或推送二次验证 + 登录通知 |
| 不安全的传输信道 | 登录接口使用HTTP传输,或HTTPS但未正确实现HSTS | 中间人攻击(MITM)嗅探凭证 | 全站强制HTTPS + HSTS预加载 + 后端拒绝HTTP请求 |
| 登录凭证存储在不安全的位置 | 密码/记住我Token明文存本地Storage、URL参数、明文Cookie | XSS窃取、浏览器泄露、日志泄露 | 敏感凭证仅存HttpOnly Cookie + 短期有效 + 加密存储,禁止localStorage存Token |
4.7. 找回密码
- 重置任意用户密码
- 密码重置后新密码在返回包中
- Token验证逻辑在前端
- X-Forwarded-Host处理不正确
- 找回密码功能泄露用户敏感信息
在渗透测试中,找回密码(密码重置/忘记密码)功能是账户安全链条中最薄弱的环节之一。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固方向) |
|---|---|---|---|
| 重置任意用户密码 | 重置接口仅凭用户名/手机号/邮箱即可发送重置链接,无二次验证或归属校验 | 任意账号被接管 | 必须校验用户归属(短信/邮箱验证码)+ 随机高熵Token + 短期有效 |
| 密码重置后新密码在返回包中 | 重置成功响应直接返回明文新密码,或JSON中包含new_password字段 | 明文泄露新密码,中间人可直接获取 | 绝不在响应中返回任何密码相关信息,仅返回“重置成功”提示 |
| Token验证逻辑在前端 | 重置Token仅前端JS校验,或Token可预测、可枚举 | 可伪造/爆破重置Token,直接重置任意密码 | Token验证必须后端严格校验 + 高熵随机生成 + 绑定用户 + 一次性使用 |
| X-Forwarded-Host处理不正确 | 重置邮件链接使用X-Forwarded-Host头构造,导致可伪造主机名生成恶意链接 | 钓鱼攻击,用户点击重置链接跳转到攻击者域名 | 邮件链接必须使用后端硬编码域名或白名单校验,禁止信任X-Forwarded-Host |
| 找回密码功能泄露用户敏感信息 | 发起重置时返回差异化提示(如“该邮箱未注册”“该手机号已绑定”)或泄露部分信息 | 用户信息枚举 + 隐私泄露 | 返回统一提示(如“若账号存在,重置链接已发送”),禁止任何差异化信息 |
4.8. 修改密码
- 越权修改密码
- 修改密码没有旧密码验证
在渗透测试中,“账户注册”相关的逻辑漏洞是业务安全中最基础却又极易被忽视的一类。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| 重置任意用户密码 | 重置接口仅凭用户名/手机号/邮箱即可发送重置链接,无二次验证或归属校验 | 任意账号被接管 | 必须校验用户归属(短信/邮箱验证码)+ 随机高熵Token + 短期有效 |
| 密码重置后新密码在返回包中 | 重置成功响应直接返回明文新密码,或JSON中包含new_password字段 | 明文泄露新密码,中间人可直接获取 | 绝不在响应中返回任何密码相关信息,仅返回“重置成功”提示 |
| Token验证逻辑在前端 | 重置Token仅前端JS校验,或Token可预测、可枚举 | 可伪造/爆破重置Token,直接重置任意密码 | Token验证必须后端严格校验 + 高熵随机生成 + 绑定用户 + 一次性使用 |
| X-Forwarded-Host处理不正确 | 重置邮件链接使用X-Forwarded-Host头构造,导致可伪造主机名生成恶意链接 | 钓鱼攻击,用户点击重置链接跳转到攻击者域名 | 邮件链接必须使用后端硬编码域名或白名单校验,禁止信任X-Forwarded-Host |
| 找回密码功能泄露用户敏感信息 | 发起重置时返回差异化提示(如“该邮箱未注册”“该手机号已绑定”)或泄露部分信息 | 用户信息枚举 + 隐私泄露 | 返回统一提示(如“若账号存在,重置链接已发送”),禁止任何差异化信息 |
4.9. 申诉
- 身份伪造
- 逻辑绕过
在渗透测试中,“申诉(账号解封、风控申诉、封禁解除、实名申诉、订单异议等)”功能是业务安全中极易被滥用的环节。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| 身份伪造申诉成功 | 申诉接口仅凭上传身份证照片、手持照片等材料,未进行真人活体、OCR严格校验或人工审核不严 | 攻击者伪造他人身份解封高价值账号 | 必须强制活体检测(眨眼、转头)+ OCR交叉校验姓名/身份证号 + 公安接口核验(若适用)+ 人工复核 |
| 上传材料未严格校验 | 可上传任意格式/大小文件、未校验文件头、未限制后缀,或服务端未重命名存储 | 上传webshell接管服务器,或伪造材料通过审核 | 严格白名单后缀(jpg/png)+ MIME校验 + 服务器重命名 + 存储隔离域 |
| 申诉Token/订单ID可预测或遍历 | 申诉接口凭申诉ID或Token提交材料,ID为递增序列或弱随机 | 横向申诉他人账号,批量解封 | 使用高熵UUID作为申诉ID + 绑定原用户ID + 后端严格归属校验 |
| 逻辑绕过(无需材料直接通过) | 申诉接口状态字段可控(如status=approved)、或审核接口无权限校验 | 无需任何材料直接解封任意账号 | 所有审核状态变更必须后台/人工操作,前端/接口禁止可控 + 幂等性校验 |
| 重复申诉/重放通过 | 申诉成功包可重放,或无防重机制 | 多次触发解封、恢复余额、解除限制 | 引入一次性nonce + 申诉记录状态机(已通过不可重复)+ Redis幂等锁 |
| 申诉信息泄露他人隐私 | 申诉查询接口返回他人申诉记录、材料,或响应差异化提示泄露存在性 | 隐私泄露 + 横向信息收集 | 严格校验申诉归属(只能查本人)+ 统一响应提示 |
4.10. 更新
- ORM更新操作不当可更新任意字段
- 权限限制不当可以越权修改
在渗透测试中,“更新(个人信息、资料、密码、手机号、邮箱、地址等修改)”相关的逻辑漏洞是典型的垂直/水平越权类高危问题。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| ORM更新任意字段 | 更新接口接收JSON/表单,未白名单过滤字段,直接ORM save/update全字段更新 | 修改任意敏感字段(如role=admin、balance+9999、is_vip=1) | 后端严格白名单,只允许更新指定字段;禁止ORM全对象更新,必须逐字段set |
| 可更新他人账号信息(水平越权) | 更新接口仅凭自身Token,但user_id参数可控或未校验归属 | 修改他人资料、绑定手机号、邮箱,导致账号接管 | 后端强制校验请求用户==目标user_id,或更新时不接受user_id参数 |
| 关键字段无独立权限校验 | 普通用户可修改管理员专属字段(如status、level、credits) | 垂直越权获得管理员/高权限 | 敏感字段(如权限、余额、状态)需独立权限校验 + 操作日志审计 |
| 批量更新/未幂等 | 更新接口可重复提交导致余额/积分重复加减,或并发更新覆盖 | 资金/权益异常放大或丢失 | 引入幂等性Token(nonce)+ Redis分布式锁 + 事务一致性校验 |
| 更新后未重新认证 | 修改手机号/邮箱/密码后未强制重新登录或二次验证 | 修改敏感信息后仍保持旧会话,可能被利用 | 修改核心绑定信息(密码、手机号、邮箱)后强制会话失效 + 重新认证 |
| 更新响应泄露敏感信息 | 更新成功响应返回其他用户字段或完整用户对象 | 信息泄露,便于进一步攻击 | 响应只返回必要提示(如“更新成功”),禁止返回完整用户对象 |
4.11. 信息查询
- 权限限制不当可以越权查询
- 用户信息ID可以猜测导致遍历
在渗透测试中,信息查询(个人信息、订单、地址、余额、交易记录、会员资料等查询)相关的逻辑漏洞属于典型的越权类高危问题(水平/垂直越权)。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| 水平越权查询他人信息 | 查询接口仅凭自身Token,但user_id/order_id/address_id等参数可控 | 查看/泄露他人隐私数据(手机号、地址、订单、余额) | 后端强制校验请求用户==目标资源归属用户,禁止接受可控ID或使用加密/不可预测ID |
| 垂直越权查询敏感信息 | 普通用户可通过接口查询管理员专属数据(如全量用户列表、系统日志、财务报表) | 获取高权限数据,导致进一步提权 | 敏感查询接口需独立权限校验(RBAC/ABAC)+ 操作日志审计 |
| 用户信息ID可预测/递增导致遍历 | ID为自增整数、时间戳、简单编码,可通过爆破批量获取他人信息 | 大规模用户信息泄露,辅助社工/撞库 | 使用高熵UUID或雪花算法生成ID + 防遍历限频 + 异常行为封IP |
| 查询响应泄露额外敏感信息 | 查询自己信息时返回不该暴露字段(如真实姓名、身份证、完整订单历史) | 隐私泄露,即使无越权也高危 | 响应严格白名单,只返回必要字段;敏感信息脱敏或单独接口+二次验证 |
| 无频率限制导致批量枚举 | 查询接口无IP/账号限频,可高速遍历ID | 快速拉取全量用户数据 | IP/账号/设备维度限频(Redis计数)+ 异常行为触发验证码/封禁 |
| 关联查询未校验归属 | 查询订单/地址时仅校验订单ID,未校验订单是否属于当前用户 | 通过订单ID横向查看他人关联信息 | 多层归属校验:订单→用户→当前登录用户必须一致 |
5. 2FA
- 重置密码后自动登录没有2FA
- OAuth登录没有启用2FA
- 2FA可爆破
- 2FA有条件竞争
- 修改返回值绕过
- 激活链接没有启用2FA
- 可通过CSRF禁用2FA
在渗透测试中,2FA(双因素认证、二步验证)相关的逻辑漏洞是账户安全最后一道防线中最常见的薄弱点。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| 重置密码后自动登录绕过2FA | 通过找回密码重置后直接进入已登录状态,未强制要求输入2FA验证码 | 攻击者重置密码后无需第二因素即可接管账号 | 重置密码后必须强制会话失效 + 要求完整登录流程(含2FA) |
| OAuth/第三方登录未强制2FA | 使用微信、QQ、GitHub、Google等OAuth登录时跳过2FA校验 | 攻击者通过第三方账号绑定后直接绕过2FA登录 | 所有登录方式(含OAuth、扫码、SSO)必须统一强制已启用2FA的账号进行第二因素验证 |
| 2FA验证码可暴力爆破 | 2FA接口无失败次数限制、锁定弱、或验证码位数少(4位) | 暴力破解第二因素,结合撞库完全接管 | 失败5次临时锁定30分钟 + IP/账号限频 + 验证码至少6位 + 异常行为触发额外风控 |
| 2FA验证存在条件竞争 | 并发提交多个2FA验证码,其中一个正确即可通过,多个请求同时处理 | 高并发下可并行猜解,大幅提升爆破成功率 | 后端使用分布式锁(Redis)+ 严格顺序校验 + 单次有效验证码 |
| 修改返回值/响应绕过2FA | 2FA验证接口返回JSON可篡改(如{"success":false}改true),或无签名校验 | 直接伪造2FA成功响应,跳过第二因素 | 2FA状态必须后端会话控制,前端响应仅提示,不参与逻辑判断 |
| 激活/绑定2FA链接无需当前2FA | 启用2FA的激活链接或二维码页面无需先输入当前2FA即可访问 | 攻击者若窃取会话可直接绑定新设备/禁用旧2FA | 绑定/修改/禁用2FA必须先验证当前2FA验证码 + 会话重新认证 |
| 可通过CSRF禁用/修改2FA | 禁用2FA接口无CSRF Token校验,攻击者可诱导已登录用户访问恶意页面 | 钓鱼诱导用户禁用2FA,后续直接密码登录接管 | 所有变更2FA操作必须校验CSRF Token + 二次确认 + 操作后强制重新登录 |
6. 验证码
- 验证码可重用
- 验证码可预测
- 验证码强度不够
- 验证码无时间限制或者失效时间长
- 验证码无猜测次数限制
- 验证码传递特殊的参数或不传递参数绕过
- 验证码可从返回包中直接获取
- 验证码不刷新或无效
- 验证码数量有限
- 验证码在数据包中返回
- 修改Cookie绕过
- 修改返回包绕过
- 验证码在客户端生成或校验
- 验证码可OCR或使用机器学习识别
- 验证码用于手机短信/邮箱轰炸
在渗透测试中,“验证码(图形验证码、短信验证码、邮箱验证码、滑块验证码等)”是业务逻辑安全中最常见却最容易被弱实现破坏的防护措施。即使系统引入了验证码,这类可重用、可预测、客户端校验、绕过等问题在注册、登录、密码重置、支付、提现、申诉等高危操作中仍高发,一旦被利用,前端风控基本失效。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| 验证码可重用 | 同一验证码可多次提交成功,或验证码不标记已使用 | 暴力破解/撞库成功率大幅提升 | 验证码一次性使用,后端验证后立即失效(Redis标记) |
| 验证码可预测 | 验证码为递增序列、时间戳、弱随机、固定字典 | 可直接生成有效验证码,无需识别 | 使用高熵随机源(SecureRandom/CSPRNG)+ 至少6位数字/字母混淆 |
| 验证码强度不够 | 4位纯数字、固定长度弱字符集、易OCR图形验证码 | 暴力爆破或机器识别成功率高 | 至少6位数字+字母 + 干扰线/背景 + 防OCR变形(2025年推荐行为式滑块/点选) |
| 验证码无时间限制或失效时间长 | 验证码有效期过长(如1小时)或无过期机制 | 旧验证码长期可用,便于重放攻击 | 严格限制有效期(图形60-120秒,短信/邮箱3-5分钟)+ 后端时间戳校验 |
| 验证码无猜测次数限制 | 错误验证码无失败计数、锁定弱或无IP限频 | 可无限暴力爆破验证码 | 失败3-5次锁定会话/IP 10-30分钟 + Redis分布式限流 |
| 特殊参数/不传参数绕过 | 删除验证码字段或添加debug=true等参数后仍通过校验 | 直接绕过验证码防护 | 后端必须强制校验验证码存在且正确,禁止任何特殊参数影响逻辑 |
| 验证码从返回包中直接获取 | 请求验证码接口响应中直接返回明文验证码值 | 无需识别即可获取验证码 | 绝不在响应中返回验证码明文,仅返回图片或不返回敏感信息 |
| 验证码不刷新或无效 | 请求新验证码但实际仍使用旧值,或验证码字段不参与校验 | 固定验证码或可忽略 | 每次请求生成新验证码 + 必须绑定会话 + 后端严格校验 |
| 验证码数量有限/可枚举 | 验证码从有限字典生成(如0000-9999) | 短时间内可枚举所有可能验证码 | 扩大字符集 + 增加长度 + 结合设备/IP指纹绑定 |
| 验证码在客户端生成或校验 | JS生成验证码或前端校验正确性 | 直接在浏览器控制台获取/伪造验证码 | 验证码必须后端生成 + 后端校验,前端仅展示 |
| 修改Cookie/返回包绕过 | 验证码状态存Cookie可修改,或响应success字段可篡改 | 伪造验证码验证成功 | 验证码状态后端会话控制,禁止依赖Cookie/前端响应 |
| 验证码易被OCR/机器学习识别 | 传统图形验证码干扰弱,易被tesseract、CNN模型识别 | 自动化绕过验证码防护 | 升级为行为式验证码(滑块、点选、无感验证)+ 动态干扰 |
| 短信/邮箱验证码轰炸 | 无发送频率限制、可对任意手机号/邮箱批量请求验证码 | DoS攻击导致用户被骚扰或运营商封号 | 发送限频(同一号码1分钟1次,1小时5次)+ 图形验证码前置 + 异常IP封禁 |
7. Session
- Session机制
- Session猜测 / 爆破
- Session伪造
- Session泄漏
- Session Fixation
在渗透测试中,“Session机制”相关的逻辑漏洞是会话管理安全的经典高危领域。即使系统使用现代框架(如Spring Session、Shiro、Django Session),Session猜测、伪造、泄漏、Fixation等问题在传统自研系统、老项目迁移、混合认证场景中仍高发,一旦被利用,可直接导致任意账号接管或会话劫持。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
| 漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
|---|---|---|---|
| Session ID可预测/猜测 | SessionID为弱随机、递增序列、时间戳+MD5、user_id编码等 | 攻击者可预测生成有效Session,直接登录他人账号 | 使用加密强随机源(CSPRNG)生成至少128位高熵SessionID + 定期轮换 |
| Session ID爆破/遍历 | SessionID熵低或长度短(如16-24位),可暴力枚举 | 横向劫持他人有效会话 | 增加SessionID长度(至少32字符)+ IP/设备指纹绑定 + 异常访问封禁 |
| Session伪造 | 后端未严格校验Session内容,仅凭SessionID或可反序列化伪造对象 | 伪造管理员/高权限Session | Session内容必须加密+签名(HMAC-SHA256)+ 后端不可反序列化用户可控数据 |
| Session泄漏 | SessionID通过URL传递(URL Rewrite)、日志打印、错误页面泄露、JS可读 | XSS/日志分析/中间人直接获取他人Session | 仅通过HttpOnly+Secure Cookie传递 + 禁止日志打印 + SameSite=Strict/Lax |
| Session Fixation | 登录前固定SessionID,登录后仍沿用该ID未重新生成 | 攻击者提前发送固定SessionID,诱导受害者登录后劫持 | 登录成功后必须强制重新生成SessionID并失效旧ID |
| Session未及时失效 | 注销后Session仍有效、超时时间过长、未绑定IP/设备 | 旧Session可重放,异地劫持 | 注销时后端主动销毁Session + 设置合理超时(15-30分钟)+ 绑定IP段/设备指纹 |
| 并发Session未控制 | 同一账号多处登录不互踢,旧Session并存 | 攻击者登录后原用户仍可操作,难以察觉劫持 | 启用单点登录或互踢机制(新登录踢旧)+ 登录通知 |
8. 越权
- 未授权访问
- 静态文件
- 通过特定url来防止被访问
在渗透测试中,未授权访问(Unauthorized Access)是逻辑漏洞中最常见且最容易被忽略的高危类别之一。未授权访问静态文件、备份文件、配置目录、API接口等问题在各类Web系统、后台管理、文件上传模块、云存储桶中仍高发,尤其是开发/运维阶段遗留的目录或文件未正确限制访问,导致敏感信息直接泄露或服务器接管。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
静态文件/目录未授权访问 | 直接访问 /backup、/upload、/.git、/config、/logs 等目录或文件 | 源码泄露、配置泄露、数据库凭证暴露、webshell获取 | Web服务器禁止目录列表 + .开头的隐藏文件禁止访问 + 敏感目录403/404 |
备份/源码文件直接下载 | 访问 .bak、.sql、.zip、.rar、.tar.gz、.swp、~结尾的编辑备份文件 | 全量源码/数据库泄露,可直接getshell或提权 | 禁止备份文件放在Web根目录 + 定期清理 + Web服务器拒绝执行/下载敏感后缀 |
配置/环境文件泄露 | 直接访问 .env、config.php、settings.py 、application.yml 等 | 数据库密码、API Key、密钥、调试模式暴露 | 敏感配置文件移出Web根目录 + 禁止直接访问 + 使用环境变量注入 |
静态资源/上传文件未授权 | 用户上传目录(如 /upload/、/files/)无访问控制,可直接遍历下载他人文件 | 隐私文件泄露、恶意文件(webshell)直接访问执行 | 上传路径加随机子目录 + 访问时校验归属或Token + 防遍历重命名 |
通过特定URL绕过访问限制 | 系统对敏感路径加了前端隐藏或简单判断,但后端未严格403,或存在平行路径绕过 | 绕过业务逻辑直接访问受限资源 | 后端统一权限拦截器 + 白名单路径 + 规范化路径(resolve)+ 严格返回403 |
API接口未授权访问 | 部分API接口未校验Token/Session,仅凭URL或简单参数即可调用 | 敏感操作(如查询、删除、导出)被任意执行 | 所有API必须统一认证中间件 + 敏感接口独立RBAC校验 + 未授权统一401 |
调试/测试页面遗留 | /debug、/test、/phpinfo.php、/server-status 等页面未禁用 | 系统信息、PHP配置、路径泄露,便于进一步攻击 | 生产环境禁用所有调试功能 + 删除测试页面 + Web服务器隐藏版本信息 |
- 水平越权
- 攻击者可以访问与他拥有相同权限的用户的资源
- 权限类型不变,ID改变
在渗透测试中,水平越权是业务逻辑漏洞中最隐蔽且高发的类型之一。这类漏洞在电商订单、用户资料、社交私信、文件共享、API资源查询等模块中仍普遍存在,尤其是资源ID(如user_id、order_id)使用可预测的自增整数或时间戳,且后端未严格校验归属的项目。一旦被利用,攻击者可轻松访问同权限用户的敏感资源,导致隐私泄露、数据篡改或业务异常。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固方向) |
ID参数可控导致资源越权访问 | 查询/修改接口接受user_id/order_id等参数,未校验是否属于当前登录用户 | 攻击者查看/修改他人订单、资料、余额、文件等 | 后端强制校验资源归属(当前user_id == 目标ID)+ 禁止前端传可控ID |
批量/列表接口未过滤 | 用户列表/订单列表接口返回全量数据,未按登录用户过滤 | 批量泄露同权限用户隐私信息 | 接口默认过滤当前用户 + 分页限量 + 后端动态SQL/WHERE归属校验 |
路径/URL参数越权 | 资源路径如 /user/{id}/info 可直接访问他人ID,无Token或Session绑定 | 通过URL猜解ID访问任意用户资源 | 使用加密/哈希ID(如UUID)+ 访问时后端解密校验归属 + 路径白名单 |
Cookie/Header中ID可篡改 | Session/Cookie包含user_id字段,未签名或加密 | 伪造他人ID直接访问资源 | Cookie敏感字段加密+签名(JWT/HMAC)+ 后端不信任客户端ID |
多阶段操作未全程校验 | 第一步校验归属,第二步(如确认/支付)未重复校验 | 绕过多以下内容**步验证仅限,直接您对自己操作他人完全拥有资源 | 每个加固接口测试,独立严禁用于任何未经授权归属校验的 + 事务内系统全程。 |
- 垂直越权
- 低级别攻击者可以访问高级别用户的资源
- 权限ID不变,类型改变
在渗透测试中,垂直越权是业务逻辑漏洞中危害最大的类型之一。攻击者以低权限账号(普通用户、游客)直接访问或执行仅限高级别用户(管理员、运营、客服)的资源或功能。这类漏洞在后台管理、用户中心、API接口、角色控制不严的项目中仍高发,尤其是RBAC实现粗糙、未统一权限拦截、敏感操作仅靠前端隐藏或简单判断的项目。一旦被利用,低权限用户可直接提权为管理员,导致全站失守、数据篡改、任意代码执行。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
直接访问管理员接口 | 普通用户直接访问 /admin、/manage、/system 等后台路径,无权限拦截 | 直接进入管理后台,接管全站 | 统一权限拦截器(Filter/Interceptor)+ 所有后台路径强制角色校验 + 隐藏后台入口 |
修改角色/权限字段提权 | 更新接口允许修改role、level、is_admin等字段,未校验权限 | 普通用户自提为管理员 | 敏感字段(role、权限、状态)禁止普通用户修改 + 独立权限校验 + 操作审计 |
功能复用接口未校验权限 | 普通用户调用仅管理员可用的API(如/user/list、/order/export、/system/config) | 获取全量用户数据、导出敏感信息、修改系统配置 | 每个敏感接口独立RBAC校验 + 注解@RequiresRoles + 未授权返回403 |
Cookie/Header篡改提权 | Session/Cookie中包含role字段,未签名或可修改 | 伪造管理员身份 | Cookie敏感字段加密+HMAC签名 + 后端不信任客户端角色字段 |
低权限调用高权限操作 | 普通用户执行删除用户、冻结账号、修改全局配置等操作 | 任意封禁用户、篡改系统参数 | 高危操作必须管理员角色 + 多因素二次验证 + 操作日志记录 |
调试/测试接口遗留 | /debug、/actuator、/druid、/swagger、/api-doc 等接口未限制权限 | 获取系统信息、执行SQL、查看全量API | 生产环境禁用所有调试接口 + IP白名单或强制管理员登录 |
权限判断仅前端或弱后端 | 管理员菜单前端隐藏,后端仅简单if(user.role != 'admin')判断可绕过 | 前端隐藏无效,直接调用后端功能 | 所有权限判断必须后端统一 + 禁止依赖前端隐藏 |
- 交叉越权
- 权限ID改变,类型改变
在渗透测试中,交叉越权是水平越权与垂直越权的结合体,危害极高。攻击者不仅能横向访问同级别其他用户资源,还能同时垂直提升到更高权限角色下操作他人资源。这类漏洞在多租户系统、SaaS平台、企业OA、供应链管理系统、代理分销平台中高发,尤其是角色与资源ID同时存在、后端校验不统一的项目。一旦被利用,低权限用户可直接操作管理员视角下的任意用户资源,导致全量数据泄露、任意账号接管、系统全局失守。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
角色+ID同时可控提权越权 | 接口接受role与user_id/order_id参数,未严格校验角色权限与资源归属 | 低权限用户以管理员身份操作任意用户资源 | 后端双重校验:当前用户角色必须匹配接口要求 + 目标资源必须归属当前用户或角色允许范围 |
多租户/组织ID混用提权 | 低权限用户修改tenant_id/org_id/company_id为管理员所属组织ID | 跨租户访问管理员视角下的所有资源 | 租户ID必须从Session强制读取,不可客户端提交 + 所有操作严格隔离租户 |
客服/运营视角交叉操作 | 普通用户伪装成客服角色查看/修改任意用户资料(含管理员) | 以客服身份横向+垂直操作全站用户 | 客服视角接口强制角色校验 + 操作目标user_id必须在客服管辖范围(非管理员) |
代理/分销体系交叉提权 | 下级代理修改上级代理ID或role为上级,操作上级用户的订单/佣金 | 下级代理接管上级甚至平台资源 | 层级关系后端树形校验 + 禁止向下级暴露上级可写接口 |
批量接口角色未隔离 | 批量导出/操作接口接受role参数,未校验当前用户是否拥有该角色 | 低权限批量拉取管理员视角全量数据 | 批量接口强制使用当前Session角色 + 禁止role参数可控 |
关联资源链条交叉越权 | 先水平越权获取他人订单 → 再以此订单视角调用管理员专属修改接口 | 通过水平入口进入垂直操作链 | 每个环节独立双重校验(归属 + 角色)+ 事务内全程一致性 |
9. 随机数安全
- 使用不安全的随机数发生器
- 使用时间等易猜解的因素作为随机数种子
在渗透测试中,随机数安全相关的逻辑漏洞是密码重置、验证码生成、临时Token、订单号、邀请码、文件命名等功能中最容易被低估却危害极大的薄弱点。使用不安全的随机数生成器(弱PRNG)或以时间、可预测因素作为种子,仍在大中型系统(尤其是老项目、PHP/Java自研框架、部分Go/Python实现)中高发。一旦被利用,攻击者可预测或枚举敏感随机值,导致任意账号接管、订单伪造、邀请码爆破、文件遍历等严重后果。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
漏洞类型 | 典型触发方式 | 危害后果 | 修复建议 |
使用不安全随机数生成器 | 使用rand()、mt_rand()、Random()、Math.random()、java.util.Random等弱PRNG | 随机值熵低、可预测或可暴力枚举 | 使用加密级CSPRNG(如PHP random_bytes/random_int、Java SecureRandom、Python secrets/os.urandom、Go crypto/rand) |
时间/可预测因素作为种子 | 以time()、微秒时间戳、PID、user_id等作为rand种子或直接拼接 | 攻击者可根据时间窗口精确预测随机值 | 禁止使用时间/PID等作为种子 + 使用高熵CSPRNG + 种子定期轮换 |
密码重置Token可预测 | 重置链接Token为时间戳+MD5(user_id)、弱随机短字符串 | 预测Token直接重置任意用户密码 | Token使用128位+高熵CSPRNG + 绑定user_id加密 + 短有效期(5-15分钟) |
验证码/订单号可预测 | 订单号/验证码为时间戳+自增、弱随机6-8位数字 | 遍历订单查看他人信息、重复提交验证码 | 使用雪花算法/UUID生成订单号 + 验证码至少6位字母数字混淆 + 高熵随机 |
邀请码/临时链接弱随机 | 邀请码为6-8位base62、短随机字符串、MD5截断 | 爆破有效邀请码注册高权限/薅羊毛 | 邀请码至少16位高熵 + 绑定邀请人 + 使用率限制 + 失效机制 |
文件/图片命名弱随机 | 上传文件重命名为时间戳+弱随机、md5(time())等 | 猜解文件名直接访问他人上传文件 | 使用UUIDv4或高熵随机重命名 + 存储隔离 + 访问时归属校验 |
会话ID/临时Token弱随机 | SessionID或API临时Token使用弱随机生成 | 预测有效Session/Token劫持会话 | Session/Token必须使用CSPRNG + 至少128位 + 定期轮换 |
10. 其他
- 用户/订单/优惠券等ID生成有规律,可枚举
- 接口无权限、次数限制
- 加密算法实现误用
- 执行顺序
- 敏感信息泄露
在渗透测试中,其他类逻辑漏洞往往是前几类(越权、更新、查询、2FA、验证码、Session、未授权、随机数)之外的“杂项高危点”,但危害同样巨大。这些漏洞在电商、会员、优惠券、积分、支付、日志等模块中仍频现,尤其是ID生成规律、接口无限制、加密误用、执行顺序错误、敏感信息泄露等问题极易被忽略,却能直接导致批量数据泄露、业务滥用、资金损失或完整接管。
以下是详细的漏洞类型、触发方式、检测方法和修复建议:
漏洞类型 | 典型触发方式 | 危害后果 | 修复建议(加固方向) |
ID生成有规律可枚举 | 用户ID、订单ID、优惠券ID、积分记录ID为纯自增、时间戳+自增、简单编码 | 批量遍历他人订单/优惠券/积分记录,导致隐私泄露或薅羊毛 | 使用高熵UUIDv4、雪花算法或加密ID + 防遍历限频 + 异常枚举封IP |
接口无权限/次数限制 | 高危接口(如领券、积分兑换、签到、导出)无登录、无频率限制 | 批量领券、积分暴涨、DoS轰炸、任意导出数据 | 必须登录校验 + IP/账号/设备多维度限频(Redis)+ 关键操作图形验证码前置 |
加密算法实现误用 | 使用弱加密(如BASE64伪加密、固定密钥XOR、MD5无盐、ECB模式AES) | 密文可直接解密或彩虹表破解,泄露敏感数据 | 使用标准强加密(AES-GCM、RSA-2048)+ 随机IV + 密钥PBKDF2派生 + 定期轮换 |
业务执行顺序错误 | 先扣库存/积分再校验条件、先生成订单再校验支付、先发券再校验资格 | 并发下负库存、未支付得商品、无资格领券 | 关键业务采用“先校验再扣减”顺序 + Redis分布式锁 + 事务补偿机制 |
敏感信息泄露 | 响应返回内部IP、路径、栈迹、调试信息、用户隐私字段、错误提示差异化 | 辅助进一步攻击、精准社工、路径遍历、指纹识别 | 生产环境关闭调试 + 统一错误提示 + 响应严格白名单脱敏 + 禁止泄露服务器指纹 |
作者申明:
1. 应遵守以下中华人民共和国法律法规制定:
《中华人民共和国网络安全法》
《中华人民共和国个人信息保护法》
《中华人民共和国数据安全法》
《关键信息基础设施安全保护条例》
2. 一定要在授权范围内使用:
合法授权测试:仅在获得目标系统所有者明确书面授权的情况下使用。
合规安全测试:用于提升系统安全防护能力为目的的渗透测试活动。
教育研究目的:在合法教育机构或研究机构内部使用。
应急响应:在网络安全事件应急响应中使用。