一个面向实战的未授权访问与鉴权绕过练习靶场。通过真实业务中常见的 22 类场景，帮助你系统性地练习识别与利用未授权访问问题，并掌握相应的修复策略。
注意：目前仓库主要提供练习说明与关卡清单，后续将逐步补充每个关卡的示例服务与脚本（计划提供 docker-compose 一键启动的练习环境）。
—— 请仅在合法授权范围内进行安全测试，禁止用于任何非法用途 ——
- 安全测试工程师、渗透测试工程师、红队成员
- Web 后端、前端、移动端工程师（希望提升鉴权与安全意识）
- 安全爱好者与学生
- HTTP/HTTPS、Cookie/Session、JWT 基础
- 常见 Web 架构与鉴权模型（RBAC、SSO、Token、Session 等）
- 基础 SQL 注入、参数污染（HPP/HPF）、Host Header 攻击、IDN/Punycode 知识
- 建议工具：Burp Suite、ZAP、httpie/curl、jwt-tool、dnspython、字典爆破工具等
- 克隆仓库：
- 阅读下方关卡概览与详解，按提示在你可合法测试的环境中进行演练。
- 后续我们将补齐每个关卡的示例靶场与复现脚本，届时可本地一键启动练习环境。
- 每个关卡包含：示例场景、漏洞成因、练习目标、攻击步骤建议、自检标准、修复建议。
- 建议在演练时保留你的请求与响应（Pcap/HTTP 历史），以及复盘笔记（包括误报/真报判定）。
- 为了系统化训练，可给每个关卡打分（发现-利用-影响-修复建议四维度）。
- 覆盖注册漏洞
- 发送验证码时邮箱可篡改
- 验证码多发
- 万能密码
- 缺省密码
- 更新关联邮箱越权
- SQL 注入改密码
- gettoken 接口未授权
- JWT 弱密钥或允许 None 算法
- Cookie 特征明显（泄露关键信息）
- Druid 未授权访问
- 无会话机制导致越权（以不可遍历主键鉴权，但存在主键泄漏接口，如 openid/unionid）
- 两个站点鉴权机制复用（跨站点 JWT/令牌复用）
- 4 位数邮箱验证码爆破
- Session 覆盖
- 置空参数绕过
- 特殊字符绕过（%20、%0a 等）
- Punycode 平行越权（IDN 处理缺陷）
- 弱鉴权（可直接修改 userid/username 等）
- 邮箱覆盖（非预期字段被修改）
- 工单邮箱绕过域后缀限制
- 重置密码 Host 污染
- 重置密码参数污染
注：以上编号在“详解”部分已统一修正为 1-23，若你已有既定关卡编号，请按需要调整顺序。
- 示例场景：注册接口写入用户记录时使用 upsert/merge，或按主键更新导致“注册即覆盖”。
- 漏洞成因：唯一标识（邮箱/手机号/用户 ID）校验不足，注册流程存在“更新逻辑”。
- 练习目标：通过注册接口覆盖既有账号（重置密码或更改关键字段）。
- 攻击步骤建议：
- 抓取注册接口请求，尝试携带已有用户的主键或唯一标识；
- 观察响应与数据库变更（如邮箱被替换、密码被重置）。
- 自检标准：可稳定复现覆盖而无需拥有原账号凭据。
- 修复建议：严格区分“注册（Create）”与“修改（Update）”；对唯一键做强校验与幂等控制；关键字段只允许在受控流程中更改。
- 示例场景：验证码发送接口的收件邮箱来自前端可控参数，后端未验证与账号绑定关系。
- 漏洞成因：身份验证与绑定校验缺失。
- 练习目标：将验证码发送到攻击者控制的邮箱，进而接管目标账号的验证码流程。
- 攻击步骤建议：
- 对发送验证码接口（/send-code 或 /captcha/mail）尝试替换邮箱参数；
- 使用受控邮箱接收验证码、走后续重置流程。
- 修复建议：验证码发送目标必须从服务端侧的绑定关系获取；对每次发送做限速与风控。
- 示例场景：同一账户或同一设备短时间内可多次请求验证码，且新旧码并存或覆盖逻辑不合理。
- 漏洞成因：缺少频率限制、并发控制与状态一致性设计。
- 练习目标：利用多发逻辑造成验证码预测或干扰真实用户（DoS/社工）。
- 修复建议：限速、队列、单通道有效码、设备指纹与风险校验；验证码生命周期合理设计（单次有效，使用后失效）。
- 示例场景：登录逻辑存在缺陷（如只校验密码非空、错误地比较哈希、误用测试后门密码）。
- 漏洞成因：鉴权逻辑实现不严谨或遗留后门。
- 练习目标：在未知密码情况下通过特定输入（空字符串、固定值、特殊格式）登录成功。
- 修复建议：完善鉴权逻辑与单元测试；移除任何后门；对登录失败原因与次数做审计与限速。
- 示例场景：新建用户或特定角色默认分配弱密码（如 123456）。
- 漏洞成因：安全初始化不足、口令策略缺失。
- 练习目标：通过默认密码登录目标账号。
- 修复建议：强制首次登录改密、口令复杂度与历史策略、禁用已知弱默认密码。
- 示例场景：修改个人信息接口允许更新邮箱，但未验证“原邮箱+验证码”。
- 漏洞成因：关键绑定属性修改缺少二次确认与强鉴权。
- 练习目标：替换目标账号绑定邮箱为攻击者邮箱。
- 修复建议：修改绑定邮箱必须走“原邮箱验证 + 新邮箱确认”双向流程，并校验会话归属。
- 示例场景：密码重置或资料修改接口存在 SQL 注入，可直接 update users set password=...。
- 漏洞成因：未使用参数化查询，输入未充分校验。
- 练习目标：通过注入语句修改任意用户密码。
- 修复建议：参数化、ORM 安全操作、WAF/输入校验、最小权限数据库账号。
- 示例场景：公开接口可返回敏感令牌（重置令牌、登录 token）。
- 漏洞成因：将内部接口暴露为公网或缺少鉴权校验。
- 练习目标：获取他人 token 并利用完成重置或登录。
- 修复建议：接口最小暴露、严格鉴权、token 单次有效与短 TTL、绑定设备/会话。
- 示例场景：服务端使用弱密钥（易暴力破解），或错误地接受 alg=none 的无签名 JWT。
- 漏洞成因：JWT 配置与验证实现不当。
- 练习目标：伪造合法 JWT（提权或越权）。
- 攻击步骤建议：
- 使用 jwt-tool 猜测 HMAC 密钥或测试 alg=none；
- 构造 role=admin 等载荷后访问敏感资源。
- 修复建议：强密钥、禁用 none、白名单算法、二次校验（服务端查权限）。
- 示例场景：Cookie 明文包含 userid/username/role 等，可被篡改导致越权。
- 漏洞成因：客户端可控信息被直接用于鉴权决定。
- 练习目标：修改 Cookie 中的身份字段以访问他人资源。
- 修复建议：对客户端状态做签名或只存会话 ID，服务端二次鉴权与权限校验。
- 示例场景：/druid/ 监控面板未开启登录保护或使用默认凭据。
- 漏洞成因：默认配置暴露管理面板。
- 练习目标：访问监控面板、查看 SQL、JDBC 等敏感信息，进一步横向移动。
- 修复建议：开启身份认证、限制来源 IP、线上禁用监控面板或网段隔离。
- 示例场景：业务以不可遍历主键（如 openid/unionid）作为鉴权依据，但存在接口泄漏该主键或可推断。
- 漏洞成因：把“知道主键”当作“已鉴权”。
- 练习目标：通过获取/推断他人主键直接访问其资源。
- 修复建议：主键仅用于标识，不用于鉴权；每次访问必须结合会话/权限校验。
- 示例场景：同集团多个站点使用相同签发密钥或错误接受彼此的令牌。
- 漏洞成因：SSO/多站点令牌校验边界不清，信任域过大。
- 练习目标：在站点 A 登录后，携带其令牌访问站点 B 的受限资源。
- 修复建议：分域密钥、受众（aud）与发行者（iss）严格校验、令牌作用域隔离。
- 示例场景：验证码只有 4 位、无有效限速/设备绑定。
- 漏洞成因：验证码复杂度低、风控缺失。
- 练习目标：对验证码接口进行 0000-9999 爆破绕过验证。
- 修复建议：6 位以上、带字母混合；限速、滑块/人机校验、错误计数锁定、设备指纹。
- 示例场景：在多步修改密码流程中，通过并发与会话切换覆盖验证阶段的会话归属。
- 攻击示例（A、B 两账户）：
- 用 A 发起修改密码并完成验证码校验直到最后一步；
- 用 B 发起修改密码申请；
- 在关键步骤用 B 的 session 替换 A 的 session；
- 在最后一步将 A 的密码改为攻击者控制的值。
- 漏洞成因：流程状态与会话绑定不严，缺少事务化与会话一致性校验。
- 修复建议：每一步校验会话归属与流程状态，使用一次性令牌绑定同一会话与设备。
- 示例场景：将某个用于鉴权或业务判断的参数置空，后端分支逻辑因此跳过校验。
- 漏洞成因：后端对空值/缺失值处理不当。
- 练习目标：删除或置空参数以绕过权限判断。
- 修复建议：对缺省值做安全默认（fail-safe），服务端重新计算关键信息而非信任客户端参数。
- 示例场景：路径或主机名在不同层面解析不一致，导致绕过同源/权限校验。
- 练习目标：使用编码空格、换行等字符绕过网关或后端路由的校验。
- 修复建议：统一规范化（canonicalization），在同一层处理并拒绝异常字符；白名单路径。
- 示例场景：后端将国际化域名（Punycode）误处理为普通英文域名，从而错误信任。
- 练习目标：利用 tàrget.com（IDN）被处理成 target.com 的缺陷，绕过域名校验。
- 修复建议：严格使用 IDN 解析库并进行同一性比较，禁止松散字符串比较用于安全决策。
- 示例场景：客户端可控的身份字段被直接用于资源访问判断。
- 练习目标：篡改请求中的 userid/username 以访问他人资源。
- 修复建议：所有资源访问必须在服务端做权限校验（基于会话/角色），客户端字段仅作展示。
- 示例场景：个人信息修改接口理论上只允许改简介，但出现邮箱字段并被接受。
- 漏洞成因：后端未对可修改字段做白名单控制。
- 练习目标：向该接口提交邮箱参数覆盖绑定邮箱，最终可用“目标邮箱+攻击者密码”登录。
- 修复建议：严格字段白名单、关键字段修改二次确认与强鉴权、接口契约校验。
- 示例场景：企业内网登录要求特定后缀邮箱；第三方工单系统会为提交人生成工单邮箱并同步邮件。
- 练习目标：利用工单邮箱注册登录并接收重置邮件。
- 修复建议：不要仅凭邮箱后缀作为身份凭据；使用企业 IdP/SSO 与域内实名校验。
- 示例场景：后端使用请求头 Host 拼接重置链接（http://host/token=），可被攻击者控制。
- 练习目标：在受害者点击重置邮件后，令牌被投递到攻击者控制的主机。
- 修复建议：构造重置链接时使用服务端配置的可信域名，校验 Host/Referer，链接中加入一次性状态参数与绑定设备校验。
- 示例场景：与 22 类似，但重置域名/回调地址由参数传入，可注入为攻击者域名。
- 修复建议：严格参数白名单与校验（固定可信回调域），拒绝任意 URL；在服务端侧统一生成重置链接。
- 资源访问是否仅依赖客户端可控字段（userid/role/token）？
- 是否存在公开接口可返回敏感令牌或主键？
- 是否对验证码/重置流程做了限速、设备绑定与状态一致性校验？
- JWT 是否禁用 none 算法、使用强密钥并校验 iss/aud？
- 是否存在默认密码、万能密码或遗留后门？
- 是否对 Host/回调 URL 做了白名单与规范化处理？
- 是否对管理面板（如 /druid/）做了认证与来源限制？
- 为每个关卡提供可启动的示例服务（Node/Java/Python 混合）与 docker-compose 一键环境；
- 提供自动化检查脚本与评分体系；
- 录制每个关卡的复现与修复演示。
本项目仅用于安全教育与研究，请确保你对目标系统拥有合法授权。任何将本项目用于未授权的攻击、违法行为的举动均与作者无关。
欢迎通过 Issue/PR 提供示例、题目优化与修复建议。
本项目采用 MIT License。