【代码审计】鉴权分析方法论个人总结分享

admin 2026-07-15 05:15:48 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 本文总结了代码审计中常见的六类鉴权问题,包括未配置鉴权、白名单放行敏感接口、路径归一化缺失导致绕过、Debug后门、Token校验不规范及注解鉴权漏配导致垂直越权。文章提供了自研鉴权审计流程和AI辅助审计的skill分享,强调人工与AI结合的重要性,旨在帮助安全人员提升鉴权分析效率。 综合评分: 87 文章分类: 代码审计,WEB安全,安全开发,渗透测试,红队


cover_image

【代码审计】鉴权分析方法论个人总结分享

原创

chunliunai chunliunai

chunliunai

2026年6月6日 18:27 北京

在小说阅读器读本章

去阅读

本篇文章记录分享一下主包最近实习对各类系统进行代码审计总结积累的几个常见的鉴权问题,并写了一个简单的ai的skill用于进行辅助鉴权分析

一、鉴权的两层模型

认证层(AuthN)—— 你是谁?你有没有合法身份进来?——未授权问题

授权层(AuthZ)—— 你能干什么?有没有权限访问这个资源?——垂直越权问题

二、六类核心问题

    排列逻辑:有没有鉴权 → 鉴权能绕过 → 鉴权能伪造身份 → 进来了权限仍有问题

问题 1|未配置鉴权

根因: 部分路由完全未被鉴权逻辑覆盖,直接裸奔。

常见形态:

  • Filter的addUrlPatterns只覆盖了 /api/*,遗漏 /internal/*
  • 多个微服务中,网关做了鉴权但服务本身无二次校验(内网直打绕过网关)

审计位置: Filter / Interceptor 的 URL 匹配规则,找”没有任何鉴权覆盖的路径”

问题 2|白名单放行接口过于敏感

根因: 鉴权存在,但白名单设计不合理,敏感接口被无条件放行。

成因分两种(定性不同,修复方向不同):

| 成因 | 归类 | | — | — | | 历史遗留,功能已敏感但忘记从白名单删除 | 白名单维护缺失 | | 设计时认为不敏感,但实际功能超出预期 | 接口安全设计缺陷 |

审计位置: Filter / Interceptor 的白名单配置

问题 3|路径归一化缺失 + 白名单模糊匹配 → 未授权绕过

    根因: 白名单过滤决策与实际路由解析语义不一致,可构造特殊路径绕过。

常见绕过手法:

       1.路径穿越:/api/public/../admin

2.参数匹配 /admin;init

代码层面两个缺陷同时存在才会触发:

  1. URI 未做归一化(使用getrequestURL或者getrequestURI来接收路由)
  2. 白名单使用 startsWith / contains 等模糊匹配,而非精确前缀 + 归一化后比对

审计位置: Filter / Interceptor 中白名单判断逻辑 + URI 获取方式

示例鉴权逻辑代码:

@Componentpublic class AuthFilter implements Filter {
&nbsp; &nbsp;&nbsp;// 白名单:不需要登录就能访问的路径&nbsp; &nbsp;&nbsp;private&nbsp;static&nbsp;final&nbsp;List<String> WHITE_LIST = Arrays.asList(&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;"/api/public", &nbsp; &nbsp; &nbsp;&nbsp;// 公开接口&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;"/api/login", &nbsp; &nbsp; &nbsp; &nbsp;// 登录接口&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;"/api/register"&nbsp; &nbsp; &nbsp;&nbsp;// 注册接口&nbsp; &nbsp; );
&nbsp; &nbsp;&nbsp;@Override&nbsp; &nbsp;&nbsp;public&nbsp;void&nbsp;doFilter(ServletRequest request, ServletResponse response, FilterChain chain)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;throws&nbsp;IOException, ServletException {
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;HttpServletRequest&nbsp;httpRequest&nbsp;=&nbsp;(HttpServletRequest) request;
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;// ❌ 缺陷 1:直接拿原始 URI,没有做归一化&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;String&nbsp;uri&nbsp;=&nbsp;httpRequest.getRequestURI();
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;// ❌ 缺陷 2:用 startsWith 做模糊匹配&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;boolean&nbsp;isWhite&nbsp;=&nbsp;false;&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;for&nbsp;(String whitePath : WHITE_LIST) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;if&nbsp;(uri.startsWith(whitePath)) { &nbsp;&nbsp;// 模糊匹配!&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; isWhite =&nbsp;true;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;break;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;if&nbsp;(isWhite) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; chain.doFilter(request, response); &nbsp;// ✅ 白名单,放行&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp;else&nbsp;{&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;// 检查登录态...&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; doAuthCheck(httpRequest);&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; }}

    针对这个情况,比如想要访问原本鉴权的接口比如/admin/adduser可以构造路径为/api/public/../../admin/adduser 来绕过鉴权

问题 4|Debug 后门

根因: 开发阶段的调试代码混入生产环境,刻意绕过鉴权。

常见形态:

// 参数绕过if&nbsp;("true".equals(request.getParameter("debug"))) { &nbsp; &nbsp;chain.doFilter(request, response);&nbsp;return;}// 特殊 Header 绕过if&nbsp;("hardcoded_secret".equals(request.getHeader("X-Debug-Token")))&nbsp;return&nbsp;true;// 硬编码超级账号if&nbsp;("admin".equals(user) &&&nbsp;"admin123".equals(pass)) { ... }// IP 白名单直通if&nbsp;("127.0.0.1".equals(ip)) skip auth;

审计位置: 鉴权逻辑写在哪里,后门就在哪里(Filter / Interceptor / Controller 都可能)

问题 5|Token 校验不规范

根因: 鉴权存在,但 Token 校验强度不足,攻击者可伪造合法身份。

#

① Token 伪造(校验强度不足)

| 问题 | 说明 | | — | — | | 仅 Base64 编码 | 无签名,可任意伪造 Payload | | JWT alg:none | 攻击者去掉签名,服务端仍接受 | | 弱密钥 | 可暴力破解或猜测签名密钥 | | 密钥硬编码 | 密钥写在代码/配置文件中,泄露即永久沦陷;常与弱密钥同时出现 |

② Token 生命周期管理缺陷

| 问题 | 说明 | | — | — | | Token 不过期 | 长期有效,泄露即永久失陷 | | 登出后未吊销 | Token 仍可继续使用 | | 关键字段未校验 | issaud / sub 未验证 |

审计位置: Filter / Interceptor 中 Token 解析和验证的具体逻辑

问题 6|注解鉴权漏配 → 垂直越权

根因: 身份合法进入系统后,授权层采用 Opt-in(显式声明才生效)模式,敏感接口漏配注解则默认放行。

// ⚠️ 敏感接口忘记打注解,任何登录用户都能访问@GetMapping("/admin/deleteUser")public&nbsp;Result&nbsp;deleteUser(@RequestParam&nbsp;Long&nbsp;userId) { ... }

审计位置:Controller 方法上是否有权限注解(@RequiresPermission / @PreAuthorize 等)

三、审计策略

#

自研鉴权审计流程:

Step&nbsp;1:找鉴权入口&nbsp; &nbsp; → pom.xml&nbsp;/ 项目结构,找&nbsp;Filter&nbsp;或 Interceptor 的注册位置Step&nbsp;2:看 URL 覆盖范围&nbsp; &nbsp; → 哪些路径没有被鉴权覆盖(问题&nbsp;1)Step&nbsp;3:看白名单配置&nbsp; &nbsp; → 白名单路径是否合理(问题&nbsp;2)&nbsp; &nbsp; → 白名单判断是否做了路径归一化(问题&nbsp;3)Step&nbsp;4:找可疑绕过逻辑&nbsp; &nbsp; → 参数/Header/IP 条件判断(问题&nbsp;4)Step&nbsp;5:看 Token 校验逻辑&nbsp; &nbsp; → 是验签还是只解码(问题&nbsp;5)Step&nbsp;6:扫 Controller 注解&nbsp; &nbsp; → 敏感接口是否漏配权限注解(问题&nbsp;6)

四、审计的skill分享

    基于以上的归列问题和审计策略流程,写了个ai辅助看代码的skill;可以用skill让ai针对逐个问题去分析和拆解分析.

    链接:https://github.com/chunliunai/skill

    使用指南:终端claude输入开始审计即开始自动分析,主包喜欢让ai一个点一个点分析,ai每分析一个点自己再结合ai说的内容再去看一遍,所以skill设计的是让ai一步一步来的;如果想要一下子全部自动化审计完,可以自行修改或者说明让ai帮你一下子全部跑完

    注:AI审计不全是对的,真实代码审计过程中结合ai辅助审计出来的结果与人工的判断食用更佳

    拿开源项目使用示例:

结语:本篇分享个人在代码审计当中关于鉴权分析总结的点,希望能够帮助到其他师傅,同时有不足也欢迎师傅们讨论。

| 思考:在ai时代我觉得对于代码审计来说,入门变得更加简单,开始我们不需要真的能够理解每个代码对应的方法、函数的意思;只需要能够了解审计的思路和方法论,具体的代码可以由ai来帮你看,之后在不断的审计过程中积累,就慢慢变得能够看懂代码。


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:chunliunai chunliunai chunliunai《【代码审计】鉴权分析方法论个人总结分享》

    评论:0   参与:  0