java-auth-audit

Java Authentication Mechanism Audit Tool

Scan Java Web project source code, identify authentication mechanism implementations, detect authentication bypass vulnerabilities and unauthorized access flaws.

Vulnerability Severity Classification Standard

See SEVERITY_RATING.md

Vulnerability ID format: {C/H/M/L}-AUTH-{序号}
Severity level = f(Reachability R, Impact Scope I, Exploitation Complexity C)
Score = R × 0.40 + I × 0.35 + C × 0.25, mapped to CVSS 3.1

Detection Scope Boundary

The detection scope of this skill includes only the following types:

Authentication bypass vulnerabilities (Bypass)
Unauthorized access flaws (Privilege Escalation)
Session management flaws (Session Fixation / Hijacking)
Known component vulnerabilities (CVE)

The following are not within the detection scope of this skill (even if they are also "security issues" in the usual sense):

❌ Code quality issues (non-standard naming, redundant logic, performance issues, etc.)
❌ General security vulnerabilities (SQL injection, XSS, CSRF, etc.; use specialized skills)
❌ Architecture design suggestions (lack of rate limiting, log auditing, encryption strength, etc.)
❌ Business logic reasonableness (business decisions such as whether an interface should be public)

Core Requirements

This skill must completely inspect all authentication-related code; omissions are not allowed.

✅ Identify all authentication entry points (Filter/Interceptor/annotations)
✅ Analyze the authentication status of each route
✅ Detect all potential authentication bypass patterns
✅ Provide a verification PoC for each vulnerability point
❌ Omitting any authentication configuration is prohibited
❌ Skipping the decompilation step is prohibited

Workflow

1. Project Analysis Initialization

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

Initialization steps:

Identify project type (source code/compiled/mixed)
Identify authentication framework (via configuration files and characteristic classes)
Determine whether decompilation is needed

2. Authentication Framework Identification

Framework	Identification Features	Configuration Files	Reference Materials
Shiro	`shiro.ini`, `@RequiresAuthentication`, `SecurityUtils`	`shiro.ini`, `shiro-spring.xml`	SHIRO.md
Spring Security	`@EnableWebSecurity`, `SecurityFilterChain`, `@PreAuthorize`	`SecurityConfig.java`	SPRING_SECURITY.md
JWT	`io.jsonwebtoken`, `JwtParser`, `Bearer Token`	-	JWT.md
Filter	`implements Filter`, `doFilter()`	`web.xml`	FILTER_INTERCEPTOR.md
Interceptor	`implements HandlerInterceptor`, `preHandle()`	`WebMvcConfig`	FILTER_INTERCEPTOR.md
Annotation-based authentication	`@RequiresRoles`, `@PreAuthorize`, custom annotations	-	ANNOTATION_AUTH.md

2.1 Component Version Detection (CRITICAL)

The versions of authentication-related components must be detected to identify known vulnerabilities.

For detailed vulnerable versions, see VERSION_VULNS.md

Version Identification Methods

Method 1: JAR file name identification

# 扫描 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

Method 2: pom.xml parsing

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

Method 3: MANIFEST.MF parsing

# 解压 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

Method 4: pom.properties inside JAR

# 查看 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

High-Risk Component Version Quick Reference

Component	Vulnerable Versions	CVE	Risk	Remarks
Shiro	< 1.5.2	CVE-2020-1957	Path bypass	Requires Spring
Shiro	< 1.5.3	CVE-2020-11989	Authentication bypass	Requires Spring
Shiro	< 1.6.0	CVE-2020-13933	Authentication bypass	-
Shiro	< 1.7.1	CVE-2020-17523	Authentication bypass	Requires Spring integration
Shiro	< 1.8.0	CVE-2021-41303	Path bypass	-
Shiro	< 1.9.1	CVE-2022-32532	RegEx bypass	When using regular expression matching
Shiro	< 1.11.0	CVE-2023-22602	Path bypass	Spring Boot 2.6+
Spring Security	< 5.7.5	CVE-2022-31692	Authorization bypass	-
Spring Security	< 5.4.11 / < 5.5.7 / < 5.6.4	CVE-2022-22978	RegEx bypass	Newline bypass
PAC4J	< 4.0.0	CVE-2021-44878	Authentication bypass	-
JJWT	< 0.10.0	-	Weak key risk	-

Version detection output format

## 组件版本分析

### 检测到的鉴权组件

| 组件 | 当前版本 | 最新版本 | 风险状态 |
|------|----------|----------|----------|
| 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. Decompilation phase (CRITICAL)

When source code is unavailable, the CFR decompiler must be used to decompile authentication-related classes.

For detailed strategy, see DECOMPILE_STRATEGY.md

3.1 Decompiler tool invocation

# 反编译单个鉴权类
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 Classes that must be decompiled

Type	Match pattern	Purpose
Filter	`Filter.class`, `AuthFilter.class`	Extract doFilter authentication logic
Interceptor	`*Interceptor.class`	Extract preHandle permission checks
Shiro configuration	`ShiroConfig.class`, `*Realm.class`	Extract filterChainDefinitionMap
Spring Security	`SecurityConfig.class`	Extract authorizeRequests configuration
Custom annotations	`Permission.class`, `Auth.class`	Extract annotation processing logic
Permission utility classes	`PermissionUtil.class`, `SecurityUtil.class`	Extract permission check methods

3.3 Key points for analyzing decompilation results

// 反编译后重点关注：
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. Authentication configuration analysis

4.1 Shiro configuration parsing

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

Extracted content:

Public paths: /login
Requires authentication: /api/**
Requires roles: /admin/** → admin

4.2 Spring Security configuration parsing

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

Extracted content:

Public paths: /public/**
Requires roles: /admin/** → ADMIN
Default policy: requires authentication

4.3 Filter configuration parsing

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

Analysis points:

Filter coverage scope
Uncovered paths (potential risk)

5. Route-authentication mapping

Combined with route information (the java-route-mapper skill can be used), analyze the authentication status of each API:

Status	Meaning	Risk
✅ Public	Explicitly configured as publicly accessible	None (need to confirm whether it should be public)
✅ Protected	Has complete authentication protection	None
⚠️ Authentication only	Only checks login status, no role validation	Medium (possible privilege escalation)
❌ No authentication	No authentication mechanism found	High
❓ Uncertain	Authentication logic is complex and requires manual confirmation	To be determined

6. Vulnerability detection

For detailed detection modes, see BYPASS_PATTERNS.md

6.1 Authentication bypass detection

6.1.1 Bypass via differences in URI retrieval methods (CRITICAL)

This is the most common root cause of authentication bypass and must be detected first!

For detailed principles, see URI_PARSING_BYPASS.md

Detection points: Identify the URI retrieval method used by the authentication code

Retrieval method	Is it secure	Bypass risk
`request.getRequestURI()`	❌ Insecure	Can be bypassed via `;`, encoding,`../` bypass
`request.getRequestURL()`	❌ Insecure	Same as above
`request.getServletPath()`	✅ Relatively secure	Special characters have been handled
`UrlPathHelper.getPathWithinApplication()`	✅ Recommended	Spring standard method
`HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE`	✅ Safest	Strongly associated Controller routing

High-risk code pattern detection:

// ❌ 危险：直接使用 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 绕过
}

Bypass principle:

请求: GET /api/admin;.js

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

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

6.1.2 Semicolon path parameter bypass (;.js series)

Bypass pattern	Payload example	Principle
Semicolon + static suffix	`/admin;.js`, `/admin;.css`, `/admin;.png`	Tomcat removes content after the semicolon, whitelist matches the suffix
Semicolon + path traversal	`/public;/../admin`	Combination of semicolon truncation + directory traversal
Semicolon + URL encoding	`/admin%3b.js`	URL-encoded semicolon
Semicolon + parameter	`/admin;bypass=true`	Path matrix parameter
Leading semicolon	`/;/admin`	Special handling by some parsers

Verification 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 Path normalization discrepancy bypass

Bypass pattern	Detection method	Risk
Path traversal	`/admin/../public`, `/public/../admin`	High
Double slash	`//admin`, `/api//users`	High
Dot slash	`/./admin`, `/api/./users`	High
URL-encoded slash	`/admin%2fusers`, `%2fadmin`	High
Double encoding	`/admin%252fusers`	High
Case bypass	`/ADMIN` vs `/admin`	Medium
Suffix bypass	`/admin.action` No authentication but `/admin` Has authentication	High
Trailing slash	`/admin/` vs `/admin`	Medium
Parameter pollution	`?role=admin` Overrides user role	High
Null byte	`/admin%00.jpg`	High

6.1.4 Data flow analysis (CRITICAL - avoid false positives)

After discovering suspicious code patterns, data flow analysis must be performed to avoid false positives!

Problem background: Pattern matching alone (such as discovering contains() match) is not enough to report a vulnerability. The complete usage chain of the variable must be traced to determine whether the bypass is actually effective.

Data flow analysis steps:

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

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

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

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

Questions that must be answered:

Question	Analysis points
How is the variable used subsequently?	Trace all usage points of uri after matching
What logic is executed after the bypass?	Analyze the complete code of each if/else branch
Is there a secondary check?	Check whether there are other security checks afterward
Does path traversal affect the final result?	Analyze the path handling function (such as taking the last segment)

Example: incorrect analysis vs correct analysis

// 被审计的代码
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];  // 取最后一段！
}

Analysis method	Conclusion	Correctness
❌ Pattern matching	`contains()` Can be bypassed by path traversal → report high-risk vulnerability	Incorrect
✅ Data flow analysis	After path traversal, `getActionPrefix()` still takes the last segment, permission check is unaffected → bypass ineffective	Correct

6.1.5 Multi-layer authentication architecture analysis (CRITICAL)

The complete authentication architecture must be identified, and it must be analyzed whether there are other layers intercepting after bypassing a single layer!

Typical multi-layer authentication architecture:

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

Analysis points:

Layer	Common responsibilities	Impact of bypass
Filter layer	Login check, whitelist, CSRF	Bypass may lead to unauthorized access
Interceptor layer	Session check, fine-grained permissions	Bypass may lead to privilege escalation
Action layer	Business permission verification	Bypass may lead to data leakage

Authentication types that must be distinguished:

Type	Check content	Example code	Consequences of bypass
Login check	Whether the Session is valid	`session.getAttribute("user") != null`	Unauthorized access
Permission check	Whether the user has specific permissions	`privileges.contains(actionPrefix)`	Privilege escalation access
Whitelist check	Whether the path is in the whitelist	`isIgnoreUrl(uri)`	Depends on subsequent logic

Key judgment: the semantics of obj != null

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

Analysis points:

obj != null Indicates "the user is logged in"
Whitelist bypass only affects "permission checks for logged-in users"
After unauthenticated users are allowed through, subsequent Interceptors may intercept

Multi-layer analysis checklist:

Identify all authentication layers (Filter/Interceptor/Action)
Analyze the responsibilities of each layer (login check/permission check/business verification)
Determine whether other layers intercept after bypassing a single layer
Distinguish between "bypassing login check" and "bypassing permission check"
Analyze obj != null or the business meaning of similar conditions

6.2 Privilege escalation access detection

Privilege escalation type	Detection method	Risk
Horizontal privilege escalation	The interface uses a user-controllable ID with no ownership verification	High
Vertical privilege escalation	Ordinary users can access administrative interfaces	High
Unauthorized access	The interface has no authentication at all	High

6.3 Session management detection

Issue	Detection method	Risk
Session fixation	The Session ID does not change before and after login	Medium
Session timeout too long	Session timeout > 30min	Low
Insecure Cookie	Missing HttpOnly/Secure flags	Medium

7. Report generation (CRITICAL - three files must be generated)

The following three files must be generated, none of which may be missing:

{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 Division of responsibilities among the three files (to avoid content duplication)

File	Core responsibility	Included content	Should not include
Main report	Vulnerability analysis	Vulnerability details, data flow analysis, PoC, remediation measures	Complete route list
Mapping table	Route inventory	Authentication status table for all routes	Detailed vulnerability analysis
Documentation	Audit metadata	Methodology, tools, limitations, verification guide	Specific vulnerability content

7.2 Report generation substeps (must be executed in order)

步骤 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 File integrity verification commands

# 验证三个文件都已生成
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

If any file is missing, it must be supplemented immediately!

Output format

3 files must be generated, strictly according to the fill-in templates in the references/ directory.

File	Template	Naming format	Responsibility
Main report	OUTPUT_TEMPLATE_MAIN.md	`{project_name}_auth_audit_{YYYYMMDD_HHMMSS}.md`	Vulnerability analysis and remediation recommendations
Mapping table	OUTPUT_TEMPLATE_MAPPING.md	`{project_name}_auth_mapping_{YYYYMMDD_HHMMSS}.md`	Complete route-authentication correspondence
Documentation	OUTPUT_TEMPLATE_README.md	`{project_name}_auth_README_{YYYYMMDD_HHMMSS}.md`	Audit methodology and limitations

Key rules:

3 files must be generated (not 1 and not 2)
The main report does not include the complete route list (put it in the mapping table)
The mapping table does not include detailed vulnerability analysis (put it in the main report)
The README does not include specific vulnerability content
Cross-reference links among the three files must be correct
General specification reference: java-shared/OUTPUT_STANDARD.md

Verification checklist

Before marking the audit as complete, the following checks must be performed:

Architecture analysis check

Identify the complete authentication architecture (Filter/Interceptor/Action layers)
Analyze the responsibility of each layer (login check/permission check/business validation)
Draw the authentication architecture diagram

Code analysis check

All Filters/Interceptors have been analyzed
All authentication configurations have been parsed
Every route has an authentication status annotation

Vulnerability detection check

All bypass patterns have been detected
Data flow analysis was performed for each suspicious pattern
Distinguished between "verified" and "pending verification" vulnerabilities
Analyzed whether other layers intercept after bypass

Report quality check

High-risk risks all have precondition analysis
High-risk risks all have data flow analysis
High-risk risks all have actual impact descriptions
High-risk risks all have verification PoCs (distinguishing logged-in/not-logged-in scenarios)

File integrity check (CRITICAL - three-file verification)

Main report file has been generated: {project_name}_audit/auth_audit/{project_name}_auth_audit_{timestamp}.md
Mapping table file has been generated: {project_name}_audit/auth_audit/{project_name}_auth_mapping_{timestamp}.md
Documentation has been generated: {project_name}_audit/auth_audit/{project_name}_auth_README_{timestamp}.md
The contents of the three files do not overlap (responsibilities are correctly divided)
Cross-reference links among files are correct

⚠️ If any file is missing, it must be supplemented immediately before marking as complete!

Verification recommendations

When verifying with PoC, the following scenarios must be distinguished:

Scenario matrix

Scenario	Cookie status	Test purpose
Unauthenticated access	No Cookie	Test whether authentication can be completely bypassed
Expired Session Access	With Invalid Cookie	Test whether Session validation is effective
Regular User Access	With Regular User Cookie	Test whether privilege escalation to admin functions is possible
Administrator Access	With Administrator Cookie	Control group, confirm the interface works normally

Verification Steps

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

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

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

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

PoC Template

Unauthenticated test template:

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

Authenticated test template:

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

Result Judgment Criteria

Response	Meaning in Unauthenticated State	Meaning in Authenticated State
200 + business data	❌ Critical: complete bypass	❌ High risk: unauthorized access
200 + empty/error	Possible partial bypass	Possible partial bypass
302 redirect to login	Authentication effective	Not applicable
401/403	Authentication effective	Permission check effective
500 error	Error cause needs analysis	Error cause needs analysis

Collaborate with java-route-mapper

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

Recommended process:

First use java-route-mapper to extract all routes
Use this skill to analyze the authentication status of each route
Merge to generate a complete security audit report

Troubleshooting

Problem	Solution
Unable to identify the authentication framework	Check pom.xml dependencies, look for custom Filters
Decompilation failed	Check the Java version, try single-file decompilation
Authentication logic is complex	Mark as "requires manual confirmation", provide the code location
Route information is incomplete	Run java-route-mapper first

Reference Materials

OUTPUT_TEMPLATE_MAIN.md - Main report fill-in template
OUTPUT_TEMPLATE_MAPPING.md - Mapping table fill-in template
OUTPUT_TEMPLATE_README.md - Documentation fill-in template
SHIRO.md - Apache Shiro authentication audit
SPRING_SECURITY.md - Spring Security authentication audit
JWT.md - JWT Token authentication audit
FILTER_INTERCEPTOR.md - Filter/Interceptor authentication audit
ANNOTATION_AUTH.md - Annotation-based authentication audit
SESSION_AUTH.md - Session authentication audit
BYPASS_PATTERNS.md - Authentication bypass patterns
URI_PARSING_BYPASS.md - Authentication bypass caused by URI parsing differences
VULNERABILITY_CHECKLIST.md - Vulnerability checklist
DECOMPILE_STRATEGY.md - Decompilation strategy guide

About this skill

Vulnerability Severity Classification Standard

Detection Scope Boundary

Core Requirements

Workflow

1. Project Analysis Initialization

2. Authentication Framework Identification

2.1 Component Version Detection (CRITICAL)

Version Identification Methods

High-Risk Component Version Quick Reference

Version detection output format

3. Decompilation phase (CRITICAL)

3.1 Decompiler tool invocation

3.2 Classes that must be decompiled

3.3 Key points for analyzing decompilation results

4. Authentication configuration analysis

4.1 Shiro configuration parsing

4.2 Spring Security configuration parsing

4.3 Filter configuration parsing

5. Route-authentication mapping

6. Vulnerability detection

6.1 Authentication bypass detection

6.1.1 Bypass via differences in URI retrieval methods (CRITICAL)

6.1.2 Semicolon path parameter bypass (;.js series)

6.1.3 Path normalization discrepancy bypass

6.1.4 Data flow analysis (CRITICAL - avoid false positives)

6.1.5 Multi-layer authentication architecture analysis (CRITICAL)

6.2 Privilege escalation access detection

6.3 Session management detection

7. Report generation (CRITICAL - three files must be generated)

7.1 Division of responsibilities among the three files (to avoid content duplication)

7.2 Report generation substeps (must be executed in order)

7.3 File integrity verification commands

Output format

Verification checklist

Architecture analysis check

Code analysis check

Vulnerability detection check

Report quality check

File integrity check (CRITICAL - three-file verification)

Verification recommendations

Scenario matrix

Verification Steps

PoC Template

Result Judgment Criteria

Collaborate with java-route-mapper

Troubleshooting

Reference Materials