java-auth-audit（Java auth 审核）

Java 鉴权机制审计工具

扫描 Java Web 项目源码，识别鉴权机制实现，检测鉴权绕过漏洞和越权访问缺陷。

漏洞分级标准

详见 SEVERITY_RATING.md

• 漏洞编号格式: {C/H/M/L}-AUTH-{序号}
• 严重等级 = f(可达性 R, 影响范围 I, 利用复杂度 C)
• Score = R × 0.40 + I × 0.35 + C × 0.25，映射 CVSS 3.1

检测范围边界

本技能检测范围仅包含以下类型：

• 鉴权绕过漏洞（Bypass）
• 越权访问缺陷（Privilege Escalation）
• 会话管理缺陷（Session Fixation / Hijacking）
• 已知组件漏洞（CVE）

以下不属于本技能检测范围（即使在通常意义上也属于"安全问题"）：

• ❌ 代码质量问题（命名不规范、逻辑冗余、性能问题等）
• ❌ 通用安全漏洞（SQL 注入、XSS、CSRF 等，使用专项技能）
• ❌ 架构设计建议（缺少限流、日志审计、加密强度等）
• ❌ 业务逻辑合理性（接口是否应该公开等业务决策）

核心要求

此技能必须完整检查所有鉴权相关代码，不允许省略。

• ✅ 识别所有鉴权入口点（Filter/Interceptor/注解）
• ✅ 分析每个路由的鉴权状态
• ✅ 检测所有潜在的鉴权绕过模式
• ✅ 为每个漏洞点提供验证 PoC
• ❌ 禁止省略任何鉴权配置
• ❌ 禁止跳过反编译步骤

工作流程

1. 项目分析初始化

输入: 项目源码路径
      可选: 已知框架信息、关注的路径

初始化步骤：

1. 识别项目类型（源码/编译后/混合）
2. 识别鉴权框架（通过配置文件和特征类）
3. 确定是否需要反编译

2. 鉴权框架识别

2.1 组件版本检测（CRITICAL）

必须检测鉴权相关组件的版本，识别已知漏洞。

详细漏洞版本参见 VERSION_VULNS.md

版本识别方法

方法 1: JAR 文件名识别

# 扫描 WEB-INF/lib 目录
ls WEB-INF/lib/ | grep -E "shiro|spring-security|jwt|pac4j"

# 常见命名格式
shiro-core-1.4.0.jar          → Shiro 1.4.0
spring-security-core-5.7.3.jar → Spring Security 5.7.3
jjwt-0.9.1.jar                → JJWT 0.9.1
pac4j-core-4.0.0.jar          → PAC4J 4.0.0

方法 2: pom.xml 解析

<dependency>
    <groupId>org.apache.shiro</groupId>
    <artifactId>shiro-spring</artifactId>
    <version>1.4.0</version>  <!-- 提取版本号 -->
</dependency>

方法 3: MANIFEST.MF 解析

# 解压 JAR 查看 MANIFEST.MF
unzip -p shiro-core-1.4.0.jar META-INF/MANIFEST.MF

# 关键字段
Implementation-Version: 1.4.0
Bundle-Version: 1.4.0

方法 4: JAR 内 pom.properties

# 查看 JAR 内的 Maven 属性文件
unzip -p shiro-core.jar META-INF/maven/org.apache.shiro/shiro-core/pom.properties

# 内容示例
version=1.4.0
groupId=org.apache.shiro
artifactId=shiro-core

高危组件版本速查

版本检测输出格式

## 组件版本分析

### 检测到的鉴权组件

| 组件 | 当前版本 | 最新版本 | 风险状态 |
|------|----------|----------|----------|
| shiro-core | 1.4.0 | 1.13.0 | ❌ 存在已知漏洞 |
| spring-security-core | 5.7.3 | 6.2.0 | ⚠️ 必须升级 |
| jjwt | 0.11.2 | 0.12.3 | ✅ 安全 |

### 已知漏洞详情

=== [CVE-2020-11989] Shiro 路径绕过 ===
影响版本: < 1.5.3
当前版本: 1.4.0
风险等级: 高

漏洞描述:
- Spring 框架下 Shiro 路径匹配存在绕过
- 攻击者可通过特殊路径绕过鉴权

验证 PoC:
\```http
GET /admin/page%2f HTTP/1.1
Host: {{host}}
\```

修复建议:
- 升级 Shiro 到 1.5.3 或更高版本

3. 反编译阶段（CRITICAL）

当源码不可用时，必须使用 CFR 反编译器反编译鉴权相关类。

详细策略参见 DECOMPILE_STRATEGY.md

3.1 反编译工具调用

# 反编译单个鉴权类
java -jar {CFR_JAR} /path/to/AuthFilter.class --outputdir {output_path}/decompiled

# 反编译鉴权相关目录
find /path/to/WEB-INF/classes/com/example/security -name "*.class" | xargs java -jar {CFR_JAR} --outputdir {output_path}/decompiled

# 反编译多个指定文件
java -jar {CFR_JAR} /path/to/AuthFilter.class /path/to/SecurityConfig.class /path/to/PermissionInterceptor.class --outputdir {output_path}/decompiled

3.2 必须反编译的类

3.3 反编译结果分析要点

// 反编译后重点关注：
public class AuthFilter implements Filter {

    // 1. 白名单路径 - 可能过宽
    private static final String[] EXCLUDE_PATHS = {"/login", "/public"};

    // 2. 路径匹配逻辑 - 可能存在绕过
    private boolean isExcluded(String path) {
        return path.startsWith("/public");  // startsWith 可被绕过
    }

    // 3. 鉴权校验逻辑 - 可能存在缺陷
    if (session.getAttribute("user") == null) {
        // 仅检查是否登录，未检查角色
    }
}

4. 鉴权配置分析

4.1 Shiro 配置解析

# shiro.ini
[urls]
/login = anon
/logout = logout
/admin/** = authc, roles[admin]
/api/** = authc

提取内容：

• 公开路径: /login
• 需要认证: /api/**
• 需要角色: /admin/** → admin

4.2 Spring Security 配置解析

http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/public/**").permitAll()
    .requestMatchers("/admin/**").hasRole("ADMIN")
    .anyRequest().authenticated()
);

提取内容：

• 公开路径: /public/**
• 需要角色: /admin/** → ADMIN
• 默认策略: 需要认证

4.3 Filter 配置解析

<!-- web.xml -->
<filter-mapping>
    <filter-name>AuthFilter</filter-name>
    <url-pattern>/api/*</url-pattern>
</filter-mapping>

分析要点：

• Filter 覆盖范围
• 未覆盖的路径（潜在风险）

5. 路由-鉴权映射

结合路由信息（可使用 java-route-mapper 技能），分析每个接口的鉴权状态：

6. 漏洞检测

详细检测模式参见 BYPASS_PATTERNS.md

6.1 鉴权绕过检测

6.1.1 URI获取方法差异绕过（CRITICAL）

这是最常见的鉴权绕过根因，必须优先检测！

详细原理参见 URI_PARSING_BYPASS.md

检测要点： 识别鉴权代码使用的 URI 获取方法

高危代码模式检测：

// ❌ 危险：直接使用 getRequestURI 做鉴权判断
String uri = request.getRequestURI();
if (uri.endsWith(".js") || uri.endsWith(".css")) {
    chain.doFilter(request, response); // 可被 /admin;.js 绕过
}

// ❌ 危险：使用 contains/endsWith 做白名单匹配
if (uri.contains("/public/") || uri.startsWith("/static/")) {
    return true; // 可被 /public/../admin 绕过
}

绕过原理：

请求: GET /api/admin;.js

鉴权Filter使用: request.getRequestURI() → 返回 /api/admin;.js → 匹配.js后缀 → 放行
路由匹配使用: request.getServletPath() → 返回 /api/admin → 路由到Controller

结果: 鉴权判断为静态资源放行，但实际路由到 /api/admin 接口

6.1.2 分号路径参数绕过（;.js 系列）

验证 PoC：

# 分号后缀绕过（最常见）
GET /center/api/users;.js HTTP/1.1
Host: {{host}}

# 分号+多种后缀
GET /center/api/users;.css HTTP/1.1
GET /center/api/users;.png HTTP/1.1
GET /center/api/users;.html HTTP/1.1

# 分号+URL编码组合
GET /center/api/users%3b.js HTTP/1.1
Host: {{host}}

# 分号+路径穿越
GET /public;/../admin/users HTTP/1.1
Host: {{host}}

6.1.3 路径规范化差异绕过

6.1.4 数据流分析（CRITICAL - 避免误报）

发现可疑代码模式后，必须进行数据流分析，避免误报！

问题背景： 仅凭模式匹配（如发现 contains() 匹配）就报告漏洞是不够的。必须追踪变量的完整使用链，判断绕过是否真正有效。

数据流分析步骤：

步骤1: 识别可疑模式
  └── 发现 isIgnoreUrl() 使用 contains() 匹配

步骤2: 追踪变量使用链
  └── uri 变量在白名单匹配后如何使用？
      ├── 仅用于白名单判断 → 需继续分析后续逻辑
      └── 还用于权限检查 → 分析权限检查如何处理 uri

步骤3: 分析后续代码逻辑
  └── 例如 getActionPrefix(uri) 取最后一段
      → 路径穿越不影响最终权限判断
      → 绕过无效！

步骤4: 得出结论
  └── 白名单可被绕过，但权限检查仍有效
      → 降低风险等级或标注"需验证"

必须回答的问题：

示例：错误分析 vs 正确分析

// 被审计的代码
if (this.isIgnoreUrl(uri)) {
    chain.doFilter(request, response);  // 白名单放行
} else {
    if (privileges.contains(getActionPrefix(uri))) {  // 权限检查
        chain.doFilter(request, response);
    }
}

// getActionPrefix() 实现
public static String getActionPrefix(String uri) {
    String[] components = uri.split("/");
    return components[components.length - 1];  // 取最后一段！
}

6.1.5 多层鉴权架构分析（CRITICAL）

必须识别完整的鉴权架构，分析绕过单层后是否还有其他层拦截！

典型多层鉴权架构：

请求 → Filter层 → Interceptor层 → Action层
         │              │              │
         │              │              └── 业务逻辑中的权限检查
         │              └── Session检查、权限校验
         └── 登录检查、白名单、CSRF防护

分析要点：

必须区分的鉴权类型：

关键判断：obj!= null 的语义

// 常见模式
Object obj = session.getAttribute("user");
if (obj != null) {
    // 已登录用户 → 执行权限检查
    if (isIgnoreUrl(uri)) {
        chain.doFilter(...);  // 白名单：跳过细粒度权限检查
    } else {
        checkPermission(uri);  // 权限检查
    }
} else {
    // 未登录用户 → 放行给后续组件（可能有Interceptor拦截）
    chain.doFilter(...);
}

分析要点：

• obj!= null 表示"用户已登录"
• 白名单绕过只影响"已登录用户的权限检查"
• 未登录用户放行后，后续 Interceptor 可能会拦截

多层分析检查清单：

• 识别所有鉴权层（Filter/Interceptor/Action）
• 分析每层的职责（登录检查/权限检查/业务校验）
• 判断绕过单层后是否有其他层拦截
• 区分"绕过登录检查"和"绕过权限检查"
• 分析 obj!= null 或类似条件的业务含义

6.2 越权访问检测

6.3 会话管理检测

7. 报告生成（CRITICAL - 必须生成三个文件）

必须生成以下三个文件，缺一不可：

{project_name}_audit/auth_audit/
├── {project_name}_auth_audit_{timestamp}.md      # 主报告（漏洞分析）
├── {project_name}_auth_mapping_{timestamp}.md    # 路由-鉴权映射表
└── {project_name}_auth_README_{timestamp}.md     # 审计说明文档

7.1 三个文件的职责划分（避免内容重复）

7.2 报告生成子步骤（必须按顺序执行）

步骤 7.1: 生成主报告
  └── 创建 {project_name}_auth_audit_{timestamp}.md
      ├── 鉴权框架识别
      ├── 鉴权架构概览
      ├── 风险统计
      ├── 高危/中危/低危风险详情
      └── 修复建议总结

步骤 7.2: 生成映射表
  └── 创建 {project_name}_auth_mapping_{timestamp}.md
      ├── 按模块分组的路由表格
      ├── 鉴权状态说明
      └── 风险统计汇总

步骤 7.3: 生成审计说明文档
  └── 创建 {project_name}_auth_README_{timestamp}.md
      ├── 审计概述（目标、范围、时间）
      ├── 审计方法和工具
      ├── 审计局限性
      ├── 验证方法说明
      └── 下一步建议

步骤 7.4: 验证报告完整性（CRITICAL）
  └── 检查三个文件是否都存在
      ├── [ ] 主报告文件存在
      ├── [ ] 映射表文件存在
      └── [ ] 说明文档文件存在

7.3 文件完整性验证命令

# 验证三个文件都已生成
ls -la {project_name}_audit/auth_audit/

# 预期输出应包含：
# {project_name}_auth_audit_{timestamp}.md
# {project_name}_auth_mapping_{timestamp}.md
# {project_name}_auth_README_{timestamp}.md

如果任何文件缺失，必须立即补充！

输出格式

必须生成 3 个文件，严格按照 references/ 目录中的填充式模板生成。

关键规则：

• 必须生成 3 个文件（不是 1 个也不是 2 个）
• 主报告不包含完整路由列表（放映射表中）
• 映射表不包含漏洞详细分析（放主报告中）
• README 不包含具体漏洞内容
• 三个文件间互相引用链接必须正确
• 通用规范参考: java-shared/OUTPUT_STANDARD.md

验证检查清单

在标记审计完成前，必须执行以下检查：

架构分析检查

• 识别完整的鉴权架构（Filter/Interceptor/Action 各层）
• 分析每层的职责（登录检查/权限检查/业务校验）
• 绘制鉴权架构图

代码分析检查

• 所有 Filter/Interceptor 已分析
• 所有鉴权配置已解析
• 每个路由都有鉴权状态标注

漏洞检测检查

• 所有绕过模式已检测
• 对每个可疑模式执行了数据流分析
• 区分了"已验证"和"待验证"漏洞
• 分析了绕过后是否有其他层拦截

报告质量检查

• 高危风险都有前置条件分析
• 高危风险都有数据流分析
• 高危风险都有实际影响说明
• 高危风险都有验证 PoC（区分登录/未登录场景）

文件完整性检查（CRITICAL - 三文件验证）

• 主报告文件已生成: {project_name}_audit/auth_audit/{project_name}_auth_audit_{timestamp}.md
• 映射表文件已生成: {project_name}_audit/auth_audit/{project_name}_auth_mapping_{timestamp}.md
• 说明文档已生成: {project_name}_audit/auth_audit/{project_name}_auth_README_{timestamp}.md
• 三个文件内容不重复（职责划分正确）
• 文件间相互引用链接正确

⚠️ 如果任何文件缺失，必须立即补充后再标记完成！

验证建议

PoC 验证时必须区分以下场景：

场景矩阵

验证步骤

步骤1: 获取有效 Cookie
  └── 登录普通用户账号，获取 JSESSIONID

步骤2: 未登录状态测试
  └── 不带任何 Cookie 发送绕过请求
      ├── 成功 → 严重漏洞：完全绕过鉴权
      └── 失败（302/401/403）→ 继续步骤3

步骤3: 已登录状态测试
  └── 带普通用户 Cookie 发送绕过请求
      ├── 成功访问管理功能 → 高危：越权访问
      └── 失败 → 绕过无效或仅影响特定场景

步骤4: 分析结果
  └── 根据测试结果调整漏洞等级和描述

PoC 模板

未登录测试模板：

GET /admin/cascade_/../admin/deleteUser.action HTTP/1.1
Host: {{host}}
# 注意：不带任何 Cookie

已登录测试模板：

GET /admin/cascade_/../admin/deleteUser.action HTTP/1.1
Host: {{host}}
Cookie: JSESSIONID={{valid_session}}
# 使用普通用户的 Session

结果判断标准

与 java-route-mapper 协作

java-route-mapper              java-auth-audit-opencode
     │                                   │
     │  提取所有 HTTP 路由                │  分析每个路由的鉴权状态
     │  生成 Burp Suite 模板             │  检测鉴权绕过漏洞
     │                                   │
     └─────────────┬─────────────────────┘
                   │
                   ▼
           完整的路由 + 鉴权审计报告

推荐流程：

1. 先使用 java-route-mapper 提取所有路由
2. 使用本技能分析每个路由的鉴权状态
3. 合并生成完整的安全审计报告

故障排除

参考资料

• OUTPUT_TEMPLATE_MAIN.md - 主报告填充式模板
• OUTPUT_TEMPLATE_MAPPING.md - 映射表填充式模板
• OUTPUT_TEMPLATE_README.md - 说明文档填充式模板
• SHIRO.md - Apache Shiro 鉴权审计
• SPRING_SECURITY.md - Spring Security 鉴权审计
• JWT.md - JWT Token 鉴权审计
• FILTER_INTERCEPTOR.md - Filter/Interceptor 鉴权审计
• ANNOTATION_AUTH.md - 注解式鉴权审计
• SESSION_AUTH.md - Session 会话鉴权审计
• BYPASS_PATTERNS.md - 鉴权绕过模式
• URI_PARSING_BYPASS.md - URI解析差异导致的鉴权绕过
• VULNERABILITY_CHECKLIST.md - 漏洞检查清单
• DECOMPILE_STRATEGY.md - 反编译策略指南