ysi6701/SpringBoot-Security-Audit-Playbook
GitHub: ysi6701/SpringBoot-Security-Audit-Playbook
Spring Boot安全审计实战指南
Stars: 2 | Forks: 0
# 拿到一个 SpringBoot 项目，我会怎么做安全审计
## 1. 背景与说明
在学习 Java / SpringBoot 代码审计的过程中，我尝试从简单到复杂，对多个开源项目进行了逐步审计练习，并整理成了一系列审计报告。如果你感兴趣，也可以在我的主页中查看相关内容。
这些项目覆盖了不同的业务复杂度与安全场景，例如：
- **简单 Java Swing 桌面系统**：例如图书管理系统
- **基于 SpringBoot 的 Web 项目**：例如常见的博客系统
- **更复杂的 O2O 业务系统**：例如外卖 / 电商类项目
在这些项目中，OWASP Top 10 中的一些常见漏洞（如`A01:broken access control`；`A03:Security Misconfiguration`；`A04:Cryptographic Failures`等）往往都会出现。
但相比“知道这些漏洞”，更关键的问题是：
- **如何在拿到源码后，有条理地去发现它们？**
- **这些漏洞在 Java / SpringBoot 项目之中是怎样出现的？**
因此，这篇文章将围绕一个核心主题展开：
📌 本文适合：
- 刚接触代码审计，不知道从哪里下手的初学者
- 具备一定开发经验，希望从安全角度重新理解项目的开发者
⭐ 你需要的前置知识：
在阅读本文之前，不需要具备非常深入的安全或开发经验，但具备以下基础会更容易理解：
- **基本的 Web 漏洞知识**
例如：XSS、CSRF、文件上传漏洞、SQL 注入（SQLi）、SSRF 等
- **基本的 Java 语法**
能够看懂类、方法、参数传递，以及简单的业务逻辑
- **基本的 SpringBoot 结构**
了解 controller / service / mapper（dao） 的基本分层
- **基础的后端安全常识**
例如：认证与授权的区别、敏感数据不应明文存储、不要信任前端输入等
- **基本的数据库访问方式（MyBatis / JDBC）**
- 了解 SQL 是如何被构造和执行的
- 知道预编译（PreparedStatement）与字符串拼接的区别
📌 如果以上内容有部分不熟悉，也不影响阅读，可以在遇到具体问题时再补充学习。
👋 本文更偏“带你走一遍审计流程”，而不是对每一个漏洞进行深入讲解。
## 2. 整体审计流程概览
🔎 现在，一个项目源码摆在我们面前，我们应该从哪里开始？
❓️ 是去找一个 XSS？一个 CSRF？还是 SQL 注入？然后想办法“打穿”它？
但问题在于：如果只是随机去找漏洞，这个过程往往依赖经验甚至运气，也很难复现和总结。
❓️ 那么，有没有一种方式，可以让这个过程更加**稳定、可重复**？
*换句话说，我们是否可以通过一套合理的流程，尽可能系统性地发现代码中不合理的设计，而不是因为路径不同而产生遗漏？*
基于我个人的一些审计实践，我通常会按照如下步骤展开分析：
1. 从项目结构入手，快速了解系统的分层结构与业务模块划分
2. 查看配置类，分析全局配置与安全基线，判断系统是否具备基本的安全防护能力
3. 梳理认证与权限机制，明确用户身份是如何建立与校验的
4. 查看数据库与数据存储方式，关注敏感数据与潜在注入风险
5. 检查工具类实现，提前识别系统中可能存在的“漏洞能力”（如文件上传、XSS、SSRF 等）
6. 重点审计 Controller 层业务逻辑，结合前面发现的问题，分析接口是否存在可利用的安全风险
📌 值得注意的是：
- 在实际分析过程中，并发问题、日志记录、敏感信息泄露等，并不会单独作为一个阶段，而是会在审计具体业务接口时一并关注
- 关于第 5 步和第 6 步，不同的人可能会有不同的顺序偏好
例如：
- 可以先从 Controller 入手，明确接口调用了哪些工具类，再回头分析这些工具类是否存在安全问题（更偏“审计视角”）
- 也可以先分析工具类，提前掌握系统具备的“攻击能力”，再在 Controller 中寻找触发点，从而构造攻击链（更偏“攻击视角”）
我认为这两种方式都是合理的，可以根据个人习惯选择。
**⭐ 在接下来的内容中，这些步骤将被逐一展开，并结合具体示例进行说明。**
需要说明的是，本文重点在于**审计思路的梳理**，而非具体工具的使用。因此，你可以：
- 通过手工方式进行代码审计
- 使用静态分析工具（如 Semgrep）
- 或结合动态分析工具、甚至 AI 辅助工具
来完成整个审计过程。
## 3. 核心审计流程
### 3.1 从项目结构入手建立整体认知（项目入口）
——通俗来说，就是先看一眼项目的整体目录结构，弄清楚每一部分大致是做什么的，以及后续我们应该重点关注哪些位置。
那么，一个典型的 Java / SpringBoot 项目大概长什么样子？这里我通过两个初学者项目来简单说明。
#### 3.1.1 BigEvent：一个较为常见的 Java / SpringBoot 教学项目
下面是它的整体结构。
BigEvent-main # 项目根目录（前后端分离项目）
│
├── big-event-backend # 后端项目（Spring Boot）
│ │
│ ├── com.itheima.bigevent # Java 主包（所有代码入口）
│ │ │
│ │ ├── controller # 控制层：接收前端请求，返回响应（接口入口）
│ │ ├── service # 业务层：处理业务逻辑（核心处理）
│ │ ├── mapper # 数据访问层：操作数据库（MyBatis接口）
│ │ ├── pojo # 实体类：封装数据（如User、Article等）
│ │ │
│ │ ├── config # 配置类：Spring配置（如拦截器注册、跨域等）
│ │ ├── interceptor # 拦截器：登录校验、权限控制等
│ │ ├── exception # 异常处理：统一异常返回（全局异常处理）
│ │ ├── validation # 参数校验：表单/接口参数校验规则
│ │ ├── anno # 自定义注解：配合校验或权限使用
│ │ ├── utils # 工具类：通用工具（JWT、日期、加密等）
│ │ │
│ │ └── BigEventApplication.java # 启动类（Spring Boot 入口）
│ │
│ └── resources # ⭐ 资源目录
│ │
│ ├── application.yml # 核心配置文件（端口、数据库、JWT等）
│ ├── application-dev.yml # 开发环境配置（可选）
│ ├── application-prod.yml # 生产环境配置（可选）
│
├── big-event-frontend # 前端项目（Vue + Vite）
│ │
│ ├── src # ⭐ 前端核心源码目录
│ │ │
│ │ ├── views # 页面组件（用户看到的页面）
│ │ ├── api # 接口封装（axios请求后端）
│ │ ├── router # 路由管理（页面跳转控制）
│ │ ├── stores # 状态管理（Pinia/Vuex，全局数据）
│ │ ├── utils # 工具函数（格式化、token处理等）
│ │ ├── assets # 静态资源（图片、样式等）
│ │ │
│ │ ├── App.vue # 根组件（所有页面的入口组件）
│ │ └── main.js # 项目入口（创建Vue实例）
│ │
│ ├── vite.config.js # ⭐ Vite配置文件（开发服务器+代理）
│ │ # 👉 解决前后端跨域（最关键配置）
│ │
│ ├── package.json # 项目依赖配置（npm包管理）
│ ├── package-lock.json # 依赖锁定文件
│ ├── index.html # 页面入口HTML（挂载Vue）
│ └── node_modules/ # npm依赖（自动生成）
│
**① 分析项目结构**
从结构上可以很明显看出，这是一个基于 SpringBoot + Vue 的**前后端分离项目**。
➡️ 看到这一点，其实就已经可以提高警惕了：
前后端分离架构中，常见的安全问题包括：
- 未授权访问（接口权限控制不严）
- Token 泄露或伪造
- XSS（前端渲染不当导致）
- CSRF（在配置不当的情况下）
这也意味着，在后续的审计过程中，我们需要重点关注这些问题是否被妥善处理。
**② config**
`/big-event-backend/com.itheima.bigevent/config`
这个包中主要存放后端的各类配置类，例如：
- Web 相关配置（路径映射、拦截器等）
- 安全相关配置（认证、权限、过滤器等）
- 跨域（CORS）配置
- 请求处理规则等
从代码审计的角度来看，这一部分非常重要，因为它直接决定了：
👉 **哪些请求可以进入系统，以及这些请求在进入业务逻辑之前会经过哪些安全校验。**
换句话说，这一层是在“接口被调用之前”的第一道控制线：
- 是否允许跨域访问
- 是否需要认证
- 是否存在拦截器进行校验
- 是否关闭了某些安全机制（如 CSRF）
因此，在审计时，可以优先通过配置类快速判断：
这里需要简单关注一下项目的安全控制方式：
是通过实现 `WebMvcConfigurer` 等方式进行自定义拦截，还是基于 Spring Security 来实现统一的安全控制。
一般来说，如果是前者，更容易因为拦截不全或逻辑分散而出现问题；如果是后者，则需要关注配置是否合理，例如是否存在不必要的放行（`permitAll`）等。
这一部分在后续会结合具体代码进行详细分析。
**③ mapper**
`/big-event-backend/com.itheima.bigevent/mapper`
这一层通常用于与数据库进行直接交互。在一些项目中，也可能被进一步细分，放在 `dao` 包之下。
从审计的角度来看，这一层主要关注数据是如何被查询和拼接的。
例如：
- 对于基于 MyBatis 实现的项目，需要重点关注是否存在不安全的 `${}` 使用，这往往可能导致 SQL 注入问题
- 对于使用 MyBatis-Plus 的项目，虽然底层仍通过 Mapper 层访问数据库，但部分查询条件可能在 service 层构建（如 Wrapper）。因此，在审计时需要结合业务代码一起分析
相比之下，MyBatis-Plus 出现注入风险的概率相对较低，但并非不存在。例如：
- Wrapper 条件拼接不当
- 与 MyBatis 混用时（在一些大型项目之中是常见的），手写 SQL 仍然存在 `${}` 风险
- 动态条件可能带来的逻辑绕过问题
- 更需要警惕的是一些老项目中直接使用 JDBC 的情况。如果开发者安全意识不足，容易出现“伪预编译”（字符串拼接 SQL）的情况，此时需要逐条检查 SQL 语句的构造方式
**④ controller / service（接口与业务逻辑）**
controller 层是系统的接口入口，而 service 层则承载具体的业务逻辑实现。两者通常需要结合起来一起分析。
从流程上看：
- controller 负责接收请求、参数处理与简单校验
- service 负责具体的业务执行与数据操作
👉 因此，用户“能调用什么接口”，以及“调用后实际能做什么”，是由这两层共同决定的。
从审计的角度来看，这一部分是整个系统中最核心的分析区域，大部分漏洞都会在这里体现。
常见需要关注的问题包括：
- **水平越权**（如通过修改 ID 访问他人数据，对象级访问控制失效）
- **垂直越权**（普通用户调用管理员接口）
- **权限校验缺失或不一致**（controller 有校验，但 service 未校验，或反之）
- **过度信任前端传参**
同时，在分析时还需要结合具体业务逻辑，例如：
- 操作是否基于当前登录用户，而不是前端传入的用户信息
- 是否存在批量操作、数据遍历等风险点
- 关键业务（如下单、支付、修改权限）是否存在逻辑缺陷
这一部分是整个审计过程的核心。一般会先从 controller 层的接口入手，顺着调用链进入 service 层，分析具体业务逻辑的实现，从而判断是否存在可被利用的逻辑漏洞。
**⑤ utils**
这一层在一些项目中也可能被称为 `common`，或者被放`common`包下，主要用于存放通用工具类。例如：
- 文件上传工具类（如常见的小项目中封装的 OSS 上传逻辑）
- HTML 过滤工具类
- JWT 相关工具类
- ThreadLocalUtil 等上下文工具
从审计角度来看，这一层往往决定了系统是否具备某些“潜在漏洞能力”。例如：
- 文件上传是否缺乏校验，可能导致任意文件上传
- HTML 过滤是否不完整，可能导致 XSS
- Token 处理是否存在问题，可能影响认证安全
👉 因此，这一层不一定直接暴露漏洞，但会影响漏洞“是否能够成立”。
在实际分析中，需要结合 controller 提供的接口一起看：
- 这些工具类是否被用户可控的接口调用
- 是否可以通过这些实现不当的工具，构造攻击链（如提权、信息泄露等）
**⑥ 后端模块其他值得关注的地方**
除了上述核心模块外，后端中还有一些容易被忽略但同样重要的部分，也需要简单关注：
- `application.yml` 等配置文件
- 可能涉及数据库连接池、线程池、限流等配置
- 这些配置会直接影响系统在高并发或 DoS 场景下的可用性
- `interceptor`（拦截器）
- 常用于权限控制、登录校验等
- 需要关注拦截路径是否完整、是否存在绕过或遗漏
- `pojo`（或 `entity`）
- 定义了系统中存储和传输的数据结构
- 需要关注是否包含敏感信息（如密码、手机号等）
- 以及在存储或返回时是否进行了加密或脱敏处理
**⑦ 前端模块**
虽然常说“后端不应信任前端”，但前端的实现同样会影响漏洞是否能够成立，因此也需要简单关注。
主要可以看以下几点：
- 前端配置（如 `vite.config.js`）
- 是否存在富文本渲染（如 `v-html`、`innerHTML` 等）
- 是否有过滤机制（如 DOMPurify）
- Token 的存储方式（如放在 Cookie 中可能带来 CSRF 风险）
#### 3.1.2 Sky Take Out：一个较为常见的 Java / SpringBoot 外卖小程序教学项目
在 3.1.1 中，我们已经介绍了常见项目结构以及需要重点关注的模块。在这个项目中，整体结构并没有本质变化，但**分层更加清晰、模块拆分更加细致**。
sky-take-out-main
├── .vscode
├── demo
├── sky-common
│ └── src/main/java/com/sky
│ ├── constant // 常量类
│ ├── context // 上下文（如ThreadLocal等）
│ ├── enumeration // 枚举类
│ ├── exception // 自定义异常
│ ├── json // JSON处理
│ ├── properties // 配置属性类
│ ├── result // 返回结果封装
│ └── utils // 工具类
│
├── sky-pojo
│ └── src/main/java/com/sky
│ ├── dto // 数据传输对象（接收前端参数）
│ ├── entity // 实体类（数据库表映射）
│ └── vo // 视图对象（返回给前端）
│
└── sky-server
└── src/main/java/com/sky
├── annotation // 自定义注解
├── aspect // AOP切面
├── config // 配置类（Spring配置等）
├── controller // 控制层
├── handler // 处理器（如全局异常处理）
├── interceptor // 拦截器
├── mapper // MyBatis接口
├── service // 业务逻辑层
├── task // 定时任务
├── websocket // WebSocket相关
└── SkyApplication // 启动类
主要的不同点在于：
- 将通用能力单独拆分为 `sky-common` 模块
- 包含工具类、常量、上下文（ThreadLocal）、返回封装等
- ⭐ 审计时需要额外关注这些“公共能力”是否被不当使用，例如一些默认密码、通用逻辑可能会在这一层定义
- 将数据结构单独拆分为 `sky-pojo` 模块
- 明确区分 `dto`（输入）、`entity`（数据库）、`vo`（输出）
- ⭐ 更方便梳理数据流向，但也需要关注数据在不同层之间传递时，是否进行了必要的校验与过滤
- 核心业务集中在 `sky-server` 模块
- 包含 controller / service / mapper 等典型结构
- 同时引入了 AOP、拦截器、WebSocket、定时任务等机制
- ⭐ 审计范围更广，不仅需要关注接口本身，还需要注意切面、任务等“非直接入口”的执行逻辑
总体来说，相比 3.1.1，这类项目：
结构更加规范的项目，往往也意味着逻辑被拆分得更加分散。在审计时，需要花费更多精力跨模块跟踪调用链进行分析，否则容易遗漏细节，从而产生误判。
### 3.2 全局配置与安全基线（配置类）
### 3.3 认证与权限机制（登录接口 + 权限控制代码）
在分析认证与权限机制时，首先需要明确两个核心问题：
- 该机制能够提供哪些安全保障？
- 该机制在何种前提下才能实现这些安全保障？
反之，我们可以发现，出现漏洞的情况无非：
- 对安全机制功能的误解，将其用于无法提供保护的场景；
- 未正确遵循安全机制的使用条件，导致其安全保障失效。
本小节前半部分主要聚焦于认证凭证与会话实现层，即 Session、Cookie、JWT 等能够直接承载登录状态的具体机制；后半部分则主要聚焦于认证授权框架与权限模型层，即 OAuth2/OIDC、SSO、RBAC 等更偏向认证流程组织、信任边界划分与授权决策设计的内容。
#### 3.3.1 JWT
我们首先来分析JWT（JSON Web Token）的结构。JWT主要由三个部分组成，每部分使用 Base64Url 编码后以`.`分隔
..
- 头部 (header)用于描述令牌元信息，包括签名算法和令牌类型。典型示例如下：
{
"alg": "HS256",
"typ": "JWT"
}
- 载荷 (payload)包含实际要传递的信息，是 JWT 的核心部分，主要包括：
- 注册声明（Registered Claims）：标准字段，如
- iss（Issuer）签发者
- sub（Subject）主题，通常为用户唯一标识
- aud（Audience）接收方
- exp（Expiration Time）过期时间
- nbf（Not Before）生效时间
- iat（Issued At）签发时间
- jti（JWT ID）唯一标识符
- 公共声明（Public Claims）：应用可自定义字段，用于存放角色、权限、部门 ID 等信息。
- 私有声明（Private Claims）：完全由应用定义的字段，用于携带业务特定信息，如用户偏好、单点登录标识等。
- 签名（signature）主要由一下公式来声明，从算法上来看，很明显，这个是为了防篡改，以及完整性的。
Signature = HMACSHA256( base64UrlEncode(Header) + "." + base64UrlEncode(Payload), secret )
签名部分是JWT做无状态认证的关键，服务器无需保存任何会话的信息，只需要把header+payload丢进签名算法里面，然后比对和签名是否一致就行为了。
我们依据这个结构来一次回答上面的问题：
- JWT能够提供哪些安全保障？
- 身份认证：通过载荷中的`sub`等身份标识符来确认请求者的身份
- 数据完整性校验：篡改载荷之中的字段，会导致后面的签名校验不通过
- 权限控制：But✳这个不是天然就能够做的，需要在公共声明部分定义比如role一类的权限信息，系统才能够依赖这个做资源授权控制。
- 无状态安全管理：即上面说的仅依赖 JWT 本身即可完成认证与授权，实现安全的分布式访问。
- JWT提供安全保障的前提是什么？
- ⭐ 其实，你也发现了，JWT token几乎所有的部分，都是由用户报文提供了，仅有secret（密钥）是秘密。那么很显然，JWT的安全性几乎完全依赖于secret。这要求：
- secret不适用弱密钥，不硬编码，最好还需要轮换
- ⭐ 另外，很显然JWT的header和payload仅仅进行了base64编码，并没有加密，因此，绝对不要再这两个部分放隐私数据，比如密码，以及其他的不应该泄露的数据。
- ⭐ 其实，你也发现了一点，在JWT验证的过程之中，我们只看了token本身，没有看任何其他的东西。这意味着，不管是谁拿着A同学的token，系统都会认为此人是合法的A，并为之提供A的服务。所以，聪明的你发现了，JWT其实不防中间人攻击。需要在HTTPS或者其他安全通道使用。
下面也提供了一段JWT的生成代码，可以结合代码看看原理。
@Service
public class JwtService {
// 建议把它放到配置文件里，存 Base64 编码后的强随机密钥
@Value("${jwt.secret}")
private String secret;
private SecretKey getKey() {
return Keys.hmacShaKeyFor(Decoders.BASE64.decode(secret));
}
public String generateToken(String username, List roles) {
Instant now = Instant.now();
return Jwts.builder()
.subject(username)
.claim("roles", roles)
.issuedAt(Date.from(now))
.expiration(Date.from(now.plus(2, ChronoUnit.HOURS)))
.signWith(getKey())
.compact();
}
public Claims parseToken(String token) {
return Jwts.parser()
.verifyWith(getKey())
.build()
.parseSignedClaims(token)
.getPayload();
}
public boolean isValid(String token, String username) {
Claims claims = parseToken(token);
return username.equals(claims.getSubject())
&& claims.getExpiration().after(new Date());
}
}
从原理的角度出发了之后，我们在再看实际中的问题案例
##### 第一关：只做了解码，没有验签
@Component
public class JwtUtil {
public String getUsername(String token) throws Exception {
String[] parts = token.split("\\.");
String payloadJson = new String(
Base64.getUrlDecoder().decode(parts[1]),
StandardCharsets.UTF_8
);
ObjectMapper mapper = new ObjectMapper();
JsonNode payload = mapper.readTree(payloadJson);
return payload.get("sub").asText();
}
public List getRoles(String token) throws Exception {
String[] parts = token.split("\\.");
String payloadJson = new String(
Base64.getUrlDecoder().decode(parts[1]),
StandardCharsets.UTF_8
);
ObjectMapper mapper = new ObjectMapper();
JsonNode payload = mapper.readTree(payloadJson);
List roles = new ArrayList<>();
payload.get("roles").forEach(node -> roles.add(node.asText()));
return roles;
}
}
@GetMapping("/admin/users")
public String adminApi(@RequestHeader("Authorization") String authHeader) throws Exception {
String token = authHeader.substring(7);
List roles = JwtUtil.getRoles(token);
if (roles.contains("ADMIN")) {
return "管理员接口数据";
}
throw new ResponseStatusException(HttpStatus.FORBIDDEN);
}
在这个例子里面，服务器拿到token，只对header和payload部分做了解码，拿出了里面的role，但是没有进行验签。在这种情况下，用户随意地篡改token之中地userid，role等参数，服务器都会为之提供服务。
Signature = HMACSHA256( base64UrlEncode(Header) + "." + base64UrlEncode(Payload), secret )
##### 第二关：虽然验签了，但没有校验`exp`/`iss`/`aud`
@Service
public class JwtValidationService {
@Value("${jwt.secret}")
private String secret;
private SecretKey getKey() {
return Keys.hmacShaKeyFor(Decoders.BASE64.decode(secret));
}
public boolean isValid(String token) {
Claims claims = Jwts.parser()
.verifyWith(getKey())
.build()
.parseSignedClaims(token)
.getPayload();
// 只要 sub 不为空就算合法
return claims.getSubject() != null;
}
}
这将导致：
- 过期 token 可能仍被接受；
- 别的系统签发的 token 可能被误接受；
- 原本签发给系统 A 的 token，可能在系统 B 被错误使用。
改进地写法是，比如你可以手动校验一下
@Service
public class BetterJwtValidationService {
@Value("${jwt.secret}")
private String secret;
@Value("${jwt.issuer}")
private String expectedIssuer;
@Value("${jwt.audience}")
private String expectedAudience;
private SecretKey getKey() {
return Keys.hmacShaKeyFor(Decoders.BASE64.decode(secret));
}
public boolean isValid(String token) {
Claims claims = Jwts.parser()
.verifyWith(getKey())
.build()
.parseSignedClaims(token)
.getPayload();
Date now = new Date();
if (claims.getExpiration() == null || claims.getExpiration().before(now)) {
return false;
}
if (!expectedIssuer.equals(claims.getIssuer())) {
return false;
}
Object aud = claims.get("aud");
if (aud == null || !aud.toString().contains(expectedAudience)) {
return false;
}
return claims.getSubject() != null;
}
}
或者像spring security之中的写法
@Configuration
@EnableMethodSecurity
public class SecurityConfig {
@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
return http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/public/**").permitAll()
.anyRequest().authenticated()
)
.oauth2ResourceServer(oauth2 -> oauth2.jwt())
.build();
}
@Bean
JwtDecoder jwtDecoder() {
NimbusJwtDecoder decoder =
(NimbusJwtDecoder) JwtDecoders.fromIssuerLocation("https://idp.example.com/issuer");
OAuth2TokenValidator withIssuer = JwtValidators.createDefaultWithIssuer(
"https://idp.example.com/issuer"
);
OAuth2TokenValidator audienceValidator =
new JwtClaimValidator>("aud", aud ->
aud != null && aud.contains("order-service"));
decoder.setJwtValidator(new DelegatingOAuth2TokenValidator<>(withIssuer, audienceValidator));
return decoder;
}
}
##### 第三关：把敏感数据塞到payload里面去了
public String generateToken(User user) {
return Jwts.builder()
.subject(user.getUsername())
.claim("phone", user.getPhone())
.claim("idCard", user.getIdCard())
.claim("passwordHash", user.getPassword()) // 严重错误
.claim("salary", user.getSalary())
.issuedAt(new Date())
.expiration(Date.from(Instant.now().plus(2, ChronoUnit.HOURS)))
.signWith(getKey())
.compact();
}
这个问题很显然，JWT的载荷之中时绝不应该放敏感数据的，因为这个地方本身没有加密。 HMACSHA256在这里只提供签名的作用。
##### 第四关：不当的密钥
按照我们上面所说的，secret时JWT安全的关键。secret是JWT安全的必要不充分条件。
因此不应该：
❌ 硬编码弱密钥
private static final String SECRET = "jwt-secret";
❌ 把普通字符串直接 getBytes()
private SecretKey getKey() {
return Keys.hmacShaKeyFor("mysecret123456".getBytes(StandardCharsets.UTF_8));
}
##### 第五关：超长的有效期
public String generateToken(String username, List roles) {
Instant now = Instant.now();
return Jwts.builder()
.subject(username)
.claim("roles", roles)
.issuedAt(Date.from(now))
.expiration(Date.from(now.plus(30, ChronoUnit.DAYS))) // 30天过长
.signWith(getKey())
.compact();
}
这种设计的问题在于，长期不失效的token，会增加token泄露之后被重复的风险。
假设这个时候，设计之中还没有吊销机制，那就更可怕了。我们可怜的安全人员，只能够通过改JWT相关代码逻辑，改secret来阻止攻击者了（当然这通常并不合适）。
##### 第六关：缺乏吊销机制
这里实际上存在一个逻辑漏洞。
例如，当用户执行注销操作时，理论上应该无法继续访问系统。但由于 JWT 是无状态的，它本身并不记录用户的注销行为。这就意味着，即便用户已经注销，若手中仍持有有效的 JWT，通过签名验证和解码，该 token 仍然可以正常使用系统。换句话说，用户并没有真正完成“注销”。
因此，安全的做法是必须引入 token 吊销机制。常见实现方式是通过 Redis + 黑名单：将已注销的 token 写入黑名单，在每次请求验证之前，先检查该 token 是否在黑名单中即可。同时，需要定期清理 Redis 中已经过期的 token，以避免存储冗余。
审计时的关注点在于：用户执行 logout 后，系统是否真正吊销了 token，防止未授权访问。
##### 第七关：错误的复用
这个问题不常见，但在开发规范不严谨的情况下容易出现：
- 跨子系统复用同一 JWT 逻辑与 secret：对多个不同子系统使用同一套 JWT 签发和验证逻辑，并复用相同的 secret。
- 除非是统一认证平台，否则不推荐这种做法。否则用户持有一个子系统的 token，就可能在其他子系统中随意访问。
- 不同角色复用同一 JWT 逻辑与 secret，且缺失 role 字段
- 用户持有普通用户 token 即可访问管理员接口，这是严重安全漏洞。
- 原则上，同一套逻辑和 secret 下，必须包含 role 或权限字段；若不设置 role，则至少应使用不同 secret 区分不同权限账户。
总结来说，JWT 的安全性不仅依赖于签名算法，还取决于设计的隔离与吊销策略。缺乏这些措施，将导致 token 被错误使用或权限越权。
#### 3.3.2 Cookie / SessionId
在讨论这个问题之前，我们先区分一下Cookie和SessionID
Cookie本身更像是一种机制，是浏览器帮网站保存的一小段数据。
网站返回响应时，可以让浏览器记住一些信息，之后浏览器再访问这个网站时，会把这些信息带回去。
常常被用于，比如：
- 记住登录状态
- 记住语言/主题/购物车
- 做统计/追踪
可以理解为，我们交给浏览器一张小纸条，后面浏览器再次访问我们的网站时，会将这张小纸条**自动**地带回来。
SessionID，则通常指的是可以存在Cookies里面的一个值（也就是说放其他方面的值也可以）。专门用来标识“这次登录的是谁/这个会话是谁”。
即SessionID属于时Cookies里面可以装的一个内容。例如
Cookie: sessionid=abc123xyz
在具体的登录流程之中发送了什么？
- 你输入用户名密码登录
- 服务器验证成功
- 服务器创建一条 session 记录
- 服务器把这个 session 的编号发给浏览器，例如：
Set-Cookie: sessionid=abc123xyz; HttpOnly; Secure
- 浏览器保存这个 Cookie
- 以后每次请求，浏览器都会自动带上：
Cookie: sessionid=abc123xyz
- 服务器根据这个 sessionid 认出你是谁
以一个简单的例子看看，登录状态靠Session如何保存
##### 示例1：不适用spring security实现
首先，我们常说的http-only和same-site的配置通常是在application.yaml之中配置的，如果配置之中没有，可能需要全局搜索一下有没有，如果还没有的话，那可能就是一个问题了。
server:
servlet:
session:
timeout: 30m
cookie:
name: JSESSIONID
http-only: true
secure: true
same-site: lax
然后看WebConfig，在这个故事里面，WebConfig负责干的事情就是注册拦截器。
而这个拦截器为我们做两件事：
- 需要登录的接口，检查 Session
- 对会修改状态的请求，检查 CSRF Token
@Configuration
public class WebConfig implements WebMvcConfigurer {
public static final String SESSION_USER_ID = "LOGIN_USER_ID";
public static final String SESSION_USERNAME = "LOGIN_USERNAME";
public static final String SESSION_ROLE = "LOGIN_ROLE";
public static final String SESSION_CSRF_TOKEN = "CSRF_TOKEN";
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(new AuthInterceptor())
.addPathPatterns("/api/**")
.excludePathPatterns(
"/api/auth/login",
"/api/auth/logout" // logout 可按需要决定是否也校验 csrf
);
}
static class AuthInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request,
HttpServletResponse response,
Object handler) throws Exception {
HttpSession session = request.getSession(false);
if (session == null || session.getAttribute(SESSION_USER_ID) == null) {
writeJson(response, 401, "{\"error\":\"UNAUTHORIZED\"}");
return false;
}
if (requiresCsrfCheck(request)) {
String tokenInSession = (String) session.getAttribute(SESSION_CSRF_TOKEN);
String tokenInHeader = request.getHeader("X-CSRF-Token");
if (tokenInSession == null || !tokenInSession.equals(tokenInHeader)) {
writeJson(response, 403, "{\"error\":\"CSRF_TOKEN_INVALID\"}");
return false;
}
}
return true;
}
private boolean requiresCsrfCheck(HttpServletRequest request) {
String method = request.getMethod();
return HttpMethod.POST.matches(method)
|| HttpMethod.PUT.matches(method)
|| HttpMethod.PATCH.matches(method)
|| HttpMethod.DELETE.matches(method);
}
private void writeJson(HttpServletResponse response, int status, String body) throws Exception {
response.setStatus(status);
response.setContentType("application/json;charset=UTF-8");
response.getWriter().write(body);
}
}
}
AuthController，这个类里直接写一个仿真的用户登录逻辑，里面有用户的登录和登出逻辑
@PostMapping("/login")
public Result login(HttpServletRequest request) {
// 1. 登录校验
User user = authService.login(username, password);
// 2. 防 Session Fixation
request.changeSessionId();
// 3. 获取 Session
HttpSession session = request.getSession();
// 4. Session 只存用户ID
session.setAttribute(WebConfig.SESSION_USER_ID, user.getId());
return Result.success();
}
**关键点一**:登录成功后立即更换 SessionID，防 Session Fixation
嗯，什么是Session Fixation？有什么问题吗？再登陆后不改变SessionID的情况下，代码的逻辑就是，用户带着自己的游客SessionID登入，然后服务器不新生成SessionID，只是把这个SessionID从标记为游客改为标记成登录后的用户。
这意味着，如果我们的攻击者，事先拥有了一个SessionID，并以恶意URL，XSS，提前写Cookies等方式，塞给了用户，于是此时用户浏览器的Cookies就变成了攻击者提供的SessionID。
后面，用户进行了登录，将这个原本是有游客状态的SessionID变成了合法用户的。此时持有该SessionID的攻击，也能够用该用户的身份登录网站了。
而如果用户在登录之后，再产生一个新的SessionID，就可以避免这种SessionID被固定的风险。
**关键点二**:SessionID里面尽量放轻量级的，可信的，不敏感的东西。
通常操作是，只放一个用户ID。
session.setAttribute(WebConfig.SESSION_USER_ID, DEMO_USER_ID);
session.setAttribute(WebConfig.SESSION_USERNAME, DEMO_USERNAME);
session.setAttribute(WebConfig.SESSION_ROLE, DEMO_ROLE);
像这个例子里面，放一堆东西，甚至放ROLE，就是一个反面教材。
一方面增大了开销，另一方面造成了一个后续的风险，比如后端如果信任sessionID里面的role，而不是去数据库里面查role。
也就是说，涉及到身份和权限的内容，代码逻辑里面绝对不可以直接信任sessionID。
**关键点三**：注销时一定要invalidate()
HttpSession session = request.getSession(false);
if (session != null) {
session.invalidate();
}
一些新手开发者写的登出操作，只是return了一个登出页面。而没有注销sessionID或者JWT之类的。这样就会出现，逻辑上好像登出了，实际上再打开这个页面还是可以用，并没有实现真正意义上的注销。
**关键点四**：要注意CSRF防护
虽说我们上面似乎已经启动了所有的防护（same-site,http-only,secure）,这看起来好像安全了，但是不完全够。特别时自己写sessionid逻辑的时候，兼容旧浏览器，SameSite=None（允许跨站 Cookie），存在跨站场景（如 SSO、第三方跳转），某些接口设计不规范（例如 GET 请求存在副作用），仍然需要 CSRF 防护。
还需要加上`csrfToken`，即：
- 登录后在 Session 中生成一个随机 csrfToken，返回给前端
- 前端以后在请求头里带 X-CSRF-Token
- 服务端比对请求头和 Session 中的值
PS：原理是，Cookies会由浏览器自动发送，但是`csrfToken`在前端页面上，不会被第三方网站自动构造。
✳因此总而言之是，其实不建议自己写sesssionID这一套登录逻辑，最好还是用spring security或Spring Session现有的逻辑，假设这是一个springboot项目的话。
##### 示例2：Spring Security下的实现
首先application.yaml之中配置的同时需要注意的，不用忘记配置防护。
server:
servlet:
session:
timeout: 30m
cookie:
name: JSESSIONID
http-only: true
secure: true
same-site: lax
下面给出两种写法:
**写法一**
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
// 1. 访问控制
.authorizeHttpRequests(auth -> auth
.requestMatchers("/login", "/error", "/static/**").permitAll()
.requestMatchers("/admin/**").hasRole("ADMIN")
.anyRequest().authenticated()
)
// 2. 表单登录
.formLogin(form -> form
.loginPage("/login")
.loginProcessingUrl("/login")
.successHandler((request, response, authentication) -> {
// 登录成功后的逻辑
// 例如返回 JSON 或跳转首页
response.sendRedirect("/home");
})
.failureHandler((request, response, exception) -> {
// 登录失败后的逻辑
response.sendRedirect("/login?error");
})
.permitAll()
)
// 3. 注销
.logout(logout -> logout
.logoutUrl("/logout")
.logoutSuccessUrl("/login?logout")
.invalidateHttpSession(true)
.deleteCookies("JSESSIONID")
)
// 4. CSRF
.csrf(csrf -> csrf
// 服务端渲染页面可以用默认方案
// 前后端分离但仍然用 Session/Cookie 时，常改成 CookieCsrfTokenRepository
.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
)
// 5. Session 管理
.sessionManagement(session -> session
// 只有需要时才创建 Session，常见默认选择
.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
// 防 Session Fixation：登录后迁移 Session
.sessionFixation(fixation -> fixation.migrateSession())
// 同一账号最多一个会话；按需调整
.maximumSessions(1)
.maxSessionsPreventsLogin(false)
);
return http.build();
}
@Bean
PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
@Bean
UserDetailsService userDetailsService() {
return username -> {
// ===== 伪码 =====
// user = userRepository.findByUsername(username)
// if user == null: throw UsernameNotFoundException
// return org.springframework.security.core.userdetails.User.builder()
// .username(user.getUsername())
// .password(user.getPasswordHash()) // 数据库存的是哈希，不是明文
// .roles(user.getRoles()...)
// .disabled(!user.isEnabled())
// .accountLocked(user.isLocked())
// .build();
throw new UnsupportedOperationException("replace with real UserDetails lookup");
};
}
}
**写法二**
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/login", "/error", "/static/**").permitAll()
.requestMatchers("/admin/**").hasRole("ADMIN")
.anyRequest().authenticated()
)
.formLogin(form -> form
.loginPage("/login")
.loginProcessingUrl("/login")
.successHandler(authenticationSuccessHandler())
.failureUrl("/login?error")
.permitAll()
)
.logout(logout -> logout
.logoutUrl("/logout")
.logoutSuccessUrl("/login?logout")
.invalidateHttpSession(true)
.deleteCookies("JSESSIONID")
)
.csrf(csrf -> csrf
.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
)
.sessionManagement(session -> session
.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
.sessionFixation(fixation -> fixation.migrateSession())
.maximumSessions(1)
.maxSessionsPreventsLogin(false)
);
return http.build();
}
@Bean
AuthenticationSuccessHandler authenticationSuccessHandler() {
SavedRequestAwareAuthenticationSuccessHandler delegate =
new SavedRequestAwareAuthenticationSuccessHandler();
delegate.setDefaultTargetUrl("/home");
return (request, response, authentication) -> {
// 这里放你自己的成功后逻辑
delegate.onAuthenticationSuccess(request, response, authentication);
};
}
}
哪一个正确？——后者更加规范。
一般来说，在 Spring Security 里，自定义 successHandler 要谨慎。
它会替换框架默认的“认证成功后处理逻辑”，最常见影响是覆盖掉默认跳转行为，比如表单登录里基于 SavedRequest 的回跳。
但像 CSRF 校验、OAuth2 的 state / nonce 处理、session fixation 防护，并不主要由 successHandler 负责，通常不会因为替换 successHandler 就自动失效。
因此，除非开发者明确知道自己要接管认证成功后的后续流程，否则不建议直接完全自定义。
更常见、更稳妥的做法有两种：
1. 组合一个 SavedRequestAwareAuthenticationSuccessHandler 作为 delegate，
先执行自己的业务逻辑，再调用 delegate.onAuthenticationSuccess(...)，
这样可以保留 Spring Security 默认的成功跳转处理。
2. 继承 SavedRequestAwareAuthenticationSuccessHandler，
在 onAuthenticationSuccess(...) 中加入自己的逻辑，
然后调用 super.onAuthenticationSuccess(...)，
从而保留默认的 SavedRequest / defaultTargetUrl 处理。
PS：个人感觉spring security是代码审计里面比较难看的地方。很多东西并不是显示执行的。如果对于spring security并不是很了解，就会出现，很多东西你以为没有做其实做了，很多东西你以为框架帮你做了，实际上被覆盖了没有做。相对而言，开发者也会因为这个原因，容易产生一些误用。
后面我们可能单独以一个小节的形式来讨论spring security。
#### 3.3.3 shiro
一些老项目，特别是Java单体应用会喜欢用这个。其实在springboot体系下应该是不多的。
行业的偏向大概是
- 新项目：更多用 Spring Security
- 老项目 / 非 Spring 项目：Shiro 仍然很多
- 微服务 / 前后端分离：JWT + Spring Security 更主流
有点偏题，但是既然讨论到了认证，这个方向我们依旧讨论一下。
首先，我们要理解一下shiro登录的整个流程发生了什么：
- 前端把用户名和密码提交到后端
- 后端把它们封装成`AuthenticationToken`，最常见是`UsernamePasswordToken`。
- 拿到当前`Subject`，调用`subject.login(token)`发起认证。
- `SecurityManager`会把这次认证委托给内部的`Authenticator`，再去找合适的`Realm`。
- 能处理这个token的`Realm`会被调用，从数据库、LDAP 或其他数据源里查用户，并返回`AuthenticationInfo`；随后由`CredentialsMatcher`比对“用户提交的凭证”和“系统保存的凭证”是否一致。
- 如果`login`没抛异常，说明认证成功；这时`subject.isAuthenticated()`会返回`true`。
其中通常需要我们自己写的核心代码是放在Realm里面的。Realm……是什么？
按照官方的定义是，一个能够访问应用特定安全数据的组件。通俗来说，就是把你某个指定的数据库，文件系统或者LDAP里面的数据，翻译成Shiro能够理解的格式。
下面给出一个例子
第一段是一个典型的自定义Realm认证代码，可以看出主要做的事情就是在数据库之中查出密码摘要
public class UserRealm extends org.apache.shiro.realm.AuthorizingRealm {
private UserService userService;
public UserRealm(UserService userService) {
this.userService = userService;
}
// 授权：这里先略，重点看认证
@Override
protected org.apache.shiro.authz.AuthorizationInfo doGetAuthorizationInfo(
org.apache.shiro.subject.PrincipalCollection principals) {
return null;
}
// 认证：登录时会走这里
@Override
protected org.apache.shiro.authc.AuthenticationInfo doGetAuthenticationInfo(
org.apache.shiro.authc.AuthenticationToken token)
throws org.apache.shiro.authc.AuthenticationException {
String username = (String) token.getPrincipal();//把账户名取出来，比如"zhangsan"，getCredentials() → 取“密码”
// 1. 根据用户名查用户
User user = userService.findByUsername(username);
if (user == null) {
return null; // Shiro 会当成账号不存在
}
// 2. 返回数据库中的“正确凭证”
// 第一个参数：主身份信息，可以放用户名/用户对象/用户ID
// 第二个参数：数据库里的密码摘要
// 第三个参数：realm 名称
return new org.apache.shiro.authc.SimpleAuthenticationInfo(
user,
user.getPasswordHash(),
getName()
);
}
}
登录代码大致长整个样子
UsernamePasswordToken token =
new UsernamePasswordToken(username, password);
Subject currentUser = SecurityUtils.getSubject();
currentUser.login(token);
诶，我们定义的Realm怎么没有被调用？还有验证密码是否正确的地方在哪里？
事实上，这个地方就是Java很多框架喜欢干的一件事，你以为它没有做，其实它悄悄做了。整个调用链其实是这个样子的
Subject.login(token)
-> SecurityManager.login(...)
-> Authenticator.authenticate(...)
-> 找到能处理这个 token 的 Realm
-> 调用 Realm 获取 AuthenticationInfo
-> 做密码比对(通常是CredentialsMatcher完成的)
其实听起来和一个常规的密码匹配没有什么不同，相对普通手写登录流程的不同点在于，Shiro 会在 login(token) 之后，按照认证器和 Realm 配置，自动找到能处理该 token 的 Realm，并完成后续认证流程；默认多 Realm 策略是 AtLeastOneSuccessfulStrategy，也就是至少一个 Realm 成功就算成功。那么其实，基本的一些注意问题和普通的password认证是差不多的。
比如，你应该用更先进的哈希算法（Argon2,Bcrypt,scrypt）来存储，不要使用md5，sha1(前些年一些平台发生过用md5加密用户密码，然后被脱库全部解密的故事)，最好的情况比如可以加盐，加胡椒，这样在最不幸地被人脱库地情况下，对方以难以用现有地彩虹表进行比对快速解密。即具体用什么哈希算法，加不加盐，加不加胡椒，这个是需要你自己设计的。
然后就是日志方面的问题，一些人喜欢logger打万物，或者单纯是开发时为了调试方便后面忘记关了。一般来说，最好只打印某用户登录成功或者失败（的原因），不要把敏感数据，比如说密码打印进去，哈希过后的也不建议。通常，也没有人刻意去写把密码打印到logger里面去，就怕写切面的时候，写自动填充没有注意把密码打进去了。
另一点就是，虽说shiro会有很多失败原因，但是前端最好不要暴露细节，只打一个“用户名或密码不正确”这样会更合理。
另外值得注意的就是，Shiro不天然提供防暴力破解或者CSRF防护。
这意味着，登录接口需要自己额外地去实现放暴力破解（比如在redis里面维护一个登录次数的键值对）。
然后shiro的CSRF防护不是内置的，也就说需要单独自己再去实现一个csrf token。
#### 3.3.4 just password??（仅表单登录，无状态管理）
这种情况，在目前来看，至少不那么“流行”，但是如果说完全不存在其实也不对。仍有一些老系统，或者一些内网系统，工控设备，NAS，路由器，Jenkins……等依旧是这样的。
毕竟它有一个巨大的优点是简单，开发简单，用户理解成本也低，兼容性非常强。而且只要正确使用其实也是安全的。
不过，比起说这种方式“只有 password”，更准确的说法其实是：它不维持登录状态，或者说不做持续的会话状态管理。用户提交一次表单，服务端完成一次校验；一旦退出，或者当前访问结束，下次就需要再次输入用户名和密码重新登录。它强调的是“每次重新证明身份”，而不是“证明一次之后在一段时间内持续信任”。
从某种角度来说，这种模式甚至有它自己的安全直觉。
在一些安全要求非常严格的系统中，“不维持长期登录状态”反而可能是被刻意选择的设计。因为一旦系统不保存持续性的登录态，就意味着攻击者更难通过窃取 Cookie、劫持会话、复用令牌等方式长期冒用用户身份。用户每次重新进入关键操作前都重新认证，看起来麻烦，但在某些高敏感场景下，这种“麻烦”本身就是安全边界的一部分。
这种登录方式的安全基础，确实主要建立在密码体系本身之上，但审计时不能只关注“密码是不是做了哈希存储”，还要连同认证入口周边的一整套保护一起看。
从代码审计的角度，至少要检查以下几点：
- 是否使用适合密码场景的哈希算法存储密码，例如 Argon2id、bcrypt、scrypt，而不是 MD5、SHA-1 或单轮通用散列。
- 是否具备防自动化攻击能力，包括限速、失败惩罚、锁定策略、验证码，或其他抗撞库、抗密码喷洒措施。
- 是否避免在日志、审计记录、异常信息和调试输出中泄露密码、口令、重置令牌等敏感数据。
- 是否采用合理的口令策略，例如鼓励更长的密码或口令短语、拒绝弱口令和已泄露口令，而不是只机械强调字符种类复杂度。
- 是否妥善保护 pepper、应用密钥、数据库凭据等秘密信息，避免硬编码在代码或配置文件中。
- 是否强制使用 HTTPS/TLS，避免密码在传输过程中被窃听或篡改。
- 是否存在账号枚举问题，例如通过“账号不存在”和“密码错误”的不同提示，帮助攻击者确认有效用户名。
- 密码重置、找回密码流程是否比正常登录更薄弱（部分小网站，比如一些阅读平台会出现这样的问题）。很多系统登录流程本身做得还可以，但“忘记密码”反而成了整个认证体系里最短的一块木板。
- 高权限账户是否启用了更强的认证措施，例如 MFA、多因素校验，或者至少要求更严格的登录保护。
PS：好消息是，至少登录这部分不需要防范常规的cookie带来的csrf了，因为没有cookie，坏消息是，如果之后系统有步骤依赖浏览器自动会带上的凭证（例如 Cookie、Basic 认证凭据或客户端证书），那后续还是需要防范csrf。
这里给几个例子：
① 使用MD5加密密码。这个通常可以通过函数命名看出来，或者可以去工具类看看
employee.setPassword(DigestUtils.md5DigestAsHex(PasswordConstant.DEFAULT_PASSWORD.getBytes()));
② 使用过于弱的默认密码，在第一次登录之后，没有强制用户进行修改
public class PasswordConstant {
public static final String DEFAULT_PASSWORD = "123456";
}
③ 登录接口缺乏爆破防护，易遭受暴力破解与口令枚举攻击
/**
* 登录
*
* @param employeeLoginDTO
* @return
*/
@Operation(summary = "登录")
@Parameters({
@Parameter(name = "employeeLoginDTO", description = "登录信息", required = true)
})
@PostMapping("/login")
public Result login(@RequestBody EmployeeLoginDTO employeeLoginDTO) {
log.info("员工登录：{}", employeeLoginDTO);
Employee employee = employeeService.login(employeeLoginDTO);
// 登录成功后，生成jwt令牌
Map claims = new HashMap<>();
claims.put(JwtClaimsConstant.EMP_ID, employee.getId());
String token = JwtUtil.createJWT(
jwtProperties.getAdminSecretKey(),
jwtProperties.getAdminTtl(),
claims);
EmployeeLoginVO employeeLoginVO = EmployeeLoginVO.builder()
.id(employee.getId())
.userName(employee.getUsername())
.name(employee.getName())
.token(token)
.build();
return Result.success(employeeLoginVO);
}
/**
* 员工登录
*
* @param employeeLoginDTO
* @return
*/
public Employee login(EmployeeLoginDTO employeeLoginDTO) {
String username = employeeLoginDTO.getUsername();
String password = employeeLoginDTO.getPassword();
// 1、根据用户名查询数据库中的数据
Employee employee = employeeMapper.getByUsername(username);
// 2、处理各种异常情况（用户名不存在、密码不对、账号被锁定）
if (employee == null) {
// 账号不存在
throw new AccountNotFoundException(MessageConstant.ACCOUNT_NOT_FOUND);
}
// 密码比对
// 进行md5加密，然后再进行比对
password = DigestUtils.md5DigestAsHex(password.getBytes());
if (!password.equals(employee.getPassword())) {
// 密码错误
throw new PasswordErrorException(MessageConstant.PASSWORD_ERROR);
}
if (employee.getStatus() == StatusConstant.DISABLE) {
// 账号被锁定
throw new AccountLockedException(MessageConstant.ACCOUNT_LOCKED);
}
// 3、返回实体对象
return employee;
}
补充一点：和 Shiro 类似，Spring Security 并没有开箱即用、完整内置的防爆破/防刷子系统；它更像是提供了完善的认证架构和扩展点，例如 `AuthenticationProvider`、认证成功/失败事件、`AuthenticationFailureHandler` 等，实际项目里通常需要结合 Redis、网关限流、验证码或 MFA 自行实现登录保护策略。
另外，也不要把希望完全寄托在网关、防火墙或 WAF 上。它们可以拦截一部分高频、低质量的攻击流量，但如果业务层本身没有失败计数、冷却、锁定、二次校验等机制，攻击者仍然可能通过代理池、分布式来源或低频慢速尝试来绕过单纯的边界限流。因此，登录保护最好同时落在入口层和应用层，而不是只依赖外围设施。
#### 3.3.5 OAuth2 / OIDC
另一种非常常见的认证方式，是借助 OAuth2 实现第三方登录。比如，小明要登录网站 A，网站 A 除了支持验证码登录、账号密码登录之外，还支持微信、QQ 等第三方登录。
🤔 **以一个较早、基于 OAuth2 的第三方认证流程为例来分析：**
如果研究这一部分的安全问题，就需要先弄清楚：用户扫一个码，或者点击“允许登录”之后，到底发生了哪些动作？
- 小明在网站 A 的客户端页面上，选择“微信登录”，随后跳转到微信的授权页面完成认证与授权（现在通常是手机扫码，或者在电脑端已登录微信时直接点击确认）。
- 微信的授权服务器在用户确认授权后，会把一个`code`（授权码）返回给网站 A 的后端服务器（严格来说，通常不是返回给前端，而是通过浏览器重定向携带给后端）。
- 网站 A 的后端服务器拿着这个`code`，向微信的授权服务器请求兑换`access token`。
- 获得`access token`后，网站 A 的后端服务器便可以访问微信的资源服务器，例如获取小明的昵称、头像、openid 等信息。
- 在一些较早或非标准 OIDC 的实现中，客户端通常会继续通过用户信息接口获取身份信息，并利用 `openid`（用户在当前应用下的唯一身份标识）确认“当前登录的确实是小明”，从而完成第三方身份绑定与登录。
- 接下来，为了维持登录状态，网站 A 通常会再向小明签发自己的登录凭证，例如 Session Cookie 或 JWT。
- 之后，小明继续访问网站 A 的服务时，实际使用的是网站 A 自己签发的 JWT 或 Cookie 进行认证，而不是之前 OAuth 流程中的 code 或 access token。
基于这个原理，我们其实就可以开始分析，OAuth2/OIDC 体系中常见的误用与错误使用方式。
这种分析其实也是有技巧的。很多安全机制出现误用或错误，主要有几个原因：
- 不理解安全基础：弱密钥、错误存储不应长期保存的内容（如 code、access_token 等）
- 误解组件功能：典型如把“认证”和“授权”混为一谈
- 惰性或省略步骤：例如只接收 token 不验签、不校验有效期等
- 过度自定义或修改规范：不遵循 JWT、OAuth2、OIDC 或 RFC 的既有规范，自行设计安全逻辑
PS：其实成熟的安全机制和密码学是差不多的，很多时候不建议开发人员自己乱来，应该遵守已有的规范，一步不差
然后，我们在代码之中来看看问题怎么发生的。注意严格来说是安全逻辑的问题，因此不会给出全量代码，只会给出关键点。
##### 第一关：不校验state
@RestController
@RequestMapping("/auth/wechat")
public class WechatCallbackController {
@GetMapping("/callback")
public Map callback(@RequestParam("code") String code,
@RequestParam(value = "state", required = false) String state) {
// 错误：完全不校验 state
String accessToken = wechatService.exchangeCodeForToken(code);
WechatUser user = wechatService.fetchUser(accessToken);
String jwt = jwtService.issue(user.getOpenid());
return Map.of("token", jwt);
}
}
这个`state`是什么东西？
我们观察一下，这是随机选择的几个网站，在点到用微信或者QQ认证时的url，我们发现其中都有state这个参数
https://open.weixin.qq.com/connect/qrconnect?appid=wx8e303c65066b0f92&redirect_uri=http%3A%2F%2Fwww.wh111.com%2Fe%2Fmemberconnect%2Fwxpclogin%2Floginend.php&response_type=code&scope=snsapi_login&state=088c6c064671d292bfb51cb4bcf8376f#wechat_redirect
https://graph.qq.com/oauth2.0/show?which=Login&display=pc&client_id=100270989&response_type=code&redirect_uri=https%3A%2F%2Fpassport.csdn.net%2Faccount%2Flogin%3FpcAuthType%3Dqq%26newAuth%3Dtrue%26state%3Dtest
https://open.weixin.qq.com/connect/qrconnect?appid=wx92fa7ab65bef7873&redirect_uri=https%3A%2F%2Fwebapi.gongzicp.com%2Findex%2Fredirect%3Fcp_url%3Dhttps%253A%252F%252Fwww.gongzicp.com%252Flogin%252FthirdServiceLogin&response_type=code&scope=snsapi_login&state=cp#wechat_redirect
https://open.weixin.qq.com/connect/qrconnect?response_type=code&appid=wxe76f3cc81db632e4&redirect_uri=https%3A%2F%2Fmy.jjwxc.net%2Fbackend%2Flogin%2Fweixin%2Fcallback.php&scope=snsapi_login
https://api.weibo.com/oauth2/authorize?response_type=code&client_id=3023520088&redirect_uri=https://gw-c.nowcoder.com/api/sparta/login/oauth/callback/weibo%3Fsource=3&state=9de9765c161c4461949201f1f40b9b24&scope=follow_app_official_microblog###
https://open.weixin.qq.com/connect/qrconnect?appid=wxafc256bf83583323&redirect_uri=https%3A%2F%2Fpassport.bilibili.com%2Fpc%2Fpassport%2FsnsLogin%3Fcsrf_state%3Ddec681105d9af51dc3b873ff67f6fdb0%26sns_platform%3Dwechat%26source%3Dmain-fe-header%26go_url%3Dhttps%253A%252F%252Fwww.bilibili.com%252F&response_type=code&scope=snsapi_login&state=authorize#wechat_redirect
具体的作用就是，用户在访问我的网站，请求第三方认证的时候，我的网站生成一个random的state码，存在我的session或者数据库（通常时redis）中，然后微信回调时，会把这个state带回来。然后我验证这个state，证明，嗯这个确实是我这个网站发出的认证请求。
那么不校验state会有什么问题？
比如，当我们已经完成了找授权服务器要授权码code的部分，我们构造这样一个请求，引诱用户去点击
https://victim-app.com/auth/wechat/callback?code=CODE_ATTACKER
这个时候，用户拿着攻击者的授权码，实际上登录了攻击者的账号。如果用户在这个账户上执行一些敏感操作，比如上传某些信息，输入密码等等，会导致 信息泄露、操作滥用、信任破坏。
甚至一些更不严格的情况之下，可以诱导用户，把自己的手机号绑定到攻击者提供的微信号之上。
于是发生了login CSRF / authorization response injection。
那我们接下来讨论两个问题：
- 这种CSRF，我们常见的CSRF防护机制是否能够防护？
- 我上面提供的三个URL，存在什么问题？
⭐对于第一个问题，一些同学可能会认为，CSRF嘛，其实有很多机制可以防护，比如SameSite Cookie,CSRF Token,Referer/Origin 校验。似乎OAuth2不做校验，问题也不大……？
我们分析一下，上述的机制究竟做了什么，上面的三个机制，其实都是在已经完成了登录的情况下进行防护的。
但是像OAuth2常见下，用户正在完成登录这个动作。
- SameSite Cookie？一方面我还没有登录，一般来说没有认证的那种Cookie，无从携带Cookie。另一方面OAuth2回调请求通常是GET请求，大部分浏览器在 SameSite=Lax 下允许顶级导航 GET 请求携带 cookie。回调本质是 第三方重定向，而非跨站表单提交，因此 SameSite 对防止 OAuth2 CSRF 作用有限。
- 校验CSRF Token？我都没有登录，哪里来的CSRF token？
- 校验Referer/Origin ，OAuth2 回调来源是微信授权服务器（如 open.weixin.qq.com）或浏览器不发送 Referer。这不等于传统 CSRF 的“陌生第三方网站”，所以通过 Origin/Referer 校验也无法判断攻击者构造的恶意回调。
于是很遗憾的是，这一个地方不能够通过传统的CSRF防护机制进行防护。只能够利用state进行防护。
⭐对于第二个问题，当我们理解了上面的原理，你发现哪些url有问题？
- 第二条，`state=test`，显然是一个静态或固定值，很显然state作为一个验证功能的字段，不应该是一个可以被猜测和推断，甚至固定下来的静态值。这意味着任何人都可以伪造请求登录。（test，显然是开发测试时为了方便设置的值，竟然被上线了……）
- 第三条，同样的问题，固定的`state=cp`。此外，这条 URL 还存在多重重定向，使攻击面进一步放大，增加被滥用的可能性。
- 第四条，就更加优秀了，直接没有`state`参数了，有两种可能，一是自己实现了一个状态认证（比如放在session里面，临时缓存了一个ticket；二是直接就裸奔，没有用`state`。前者不推荐，理论上在实现正确的情况下，也能够安全，但实际上容易实现出问题来。另外，按这个网站的调性，我感觉是后者的可能更大一点。
像这个问题，小站的正确率不是很高，稍微大一点的平台，自身有明确研发部门的平台会好点。平时做登录的时候，可以关注一下这个方面的问题，感受一下。另外不是这一条url会出问题，而是后面回调（callback）会出问题
##### 第二关：token的管理问题
这个问题本质上仍然属于**安全逻辑设计**的一部分，其中一条主线就是 **token 生命周期与凭证管理**。
在 OAuth 2.0 中，客户端服务器拿授权码 `code` 去授权服务器的 token endpoint 换 token 时，通常会获得 `access_token`，有时还会额外获得 `refresh_token`。其中，`refresh_token` 是否发放是**授权服务器决定的可选能力**，不是客户端自行决定的；如果发放了，客户端就可以在 `access_token` 失效或过期后，再去换取新的 `access_token`。
这些 token 的有效期通常也由授权服务器控制。`access_token` 的生命周期通常会通过 `expires_in` 等字段返回给客户端。生命周期既不能短到频繁掉线、影响可用性，也不能长到失控，增加泄露后的风险窗口。
根据不同的角色，在OAuth2之中代码审计的重点其实也不尽相同
1. 客户端服务器需要关注的安全问题（最为常见的情景）
客户端服务器的核心职责，是**正确使用并妥善保管 token**。
需要关注的点比如：
* 正确记录 `access_token` 的过期时间，并在接近过期时决定是否刷新。
* 如果拿到了 `refresh_token`，要支持使用它向授权服务器自动换取新的 `access_token`；如果授权服务器没有提供 `refresh_token`，那么 `access_token` 过期后就只能让用户重新登录。
* 妥善保管 `access_token` 和 `refresh_token`，尤其是 `refresh_token`。因为 bearer token 一旦泄露，持有者即可使用它，OAuth 明确要求此类 token 在**存储和传输中都应避免泄露**。
* 如果授权服务器启用了 **refresh token rotation**，客户端在刷新成功后必须保存新的 `refresh_token`，不能继续使用旧的。当前最佳实践明确推荐对 refresh token 设置过期、失活和轮换机制。
* 尽量不要把 `refresh_token` 直接暴露给前端浏览器，更稳妥的做法通常是由后端安全保存并代管刷新流程。
* 刷新失败时要区分：是 token 真失效、用户撤销授权，还是系统异常；不能把所有失败都粗暴等同为“重新登录”。
2. 授权服务器需要关注的安全问题
授权服务器的职责，是**决定发什么 token、发多久、如何撤销、如何防滥用**。
需要关注的点：
* 是否发放 `refresh_token`，以及给什么类型的客户端发放。
* `access_token` 与 `refresh_token` 的生命周期设计。
* 对 `refresh_token` 做绑定、过期、失活控制和轮换，必要时设置 inactivity timeout 和最大存活时间。OAuth 当前最佳实践明确建议 refresh token 应具备过期和失活控制。
* 提供 token revocation 能力，用于撤销 `access_token` 或 `refresh_token`。
* 校验客户端身份，防止 `refresh_token` 被其他客户端冒用。OAuth 2.0 规范要求在可以认证客户端身份时，授权服务器应验证 refresh token 与客户端之间的绑定关系。
3. 资源服务器需要关注的安全问题
资源服务器的职责，是**不要盲信 access token，而要正确验证它当前是否还能用、能访问什么资源**。
需要关注的点：
* 验证 token 是否仍然有效，而不是只要拿到字符串就直接放行。
* 验证 token 的权限边界，例如 `scope`、`audience`、`issuer`、过期时间等。
* 对于 opaque token，或者需要更强实时性的场景，可以通过 token introspection 去询问授权服务器当前 token 是否仍为 `active`。RFC 7662 就是为此定义的。
* 资源服务器应只接受 `access_token` 来访问资源，而不应接受 `refresh_token` 直接调用业务接口。
* 如果资源服务器本身也是自家系统的一部分，就必须避免“过期 token 仍然放行”这类典型鉴权错误。
##### 第三关：没有区分OAuth2提供商
// 发起登录
@GetMapping("/oauth/login/{provider}")
public void login(@PathVariable String provider,
HttpServletResponse response,
HttpSession session) throws IOException {
String state = UUID.randomUUID().toString();
// 只保存 state，没有保存“本次授权选的是哪个 provider / issuer”
session.setAttribute("oauth_state", state);
OAuthClient client = clientRegistry.get(provider);
response.sendRedirect(client.buildAuthorizeUrl(state));
}
// 统一回调
@GetMapping("/oauth/callback")
public Map callback(@RequestParam("code") String code,
@RequestParam("state") String state,
@RequestParam(value = "provider", required = false) String provider,
HttpSession session) {
String expectedState = (String) session.getAttribute("oauth_state");
if (!Objects.equals(expectedState, state)) {
throw new SecurityException("invalid state");
}
// 漏洞点：
// 1) 没有从服务端会话中取“本次原本发往哪个 provider / issuer”
// 2) 反而信任回调参数里的 provider，或者走默认值
OAuthClient client = clientRegistry.getOrDefault(provider, clientRegistry.get("wechat"));
// 结果：code 会被送到“当前选中的” token endpoint，
// 而不是“最初发起授权的”那个授权服务器对应的 token endpoint
TokenResponse token = client.exchangeCode(code);
OAuthUser user = client.fetchUser(token.accessToken());
String jwt = jwtService.issue(user.getSubject());
return Map.of("token", jwt);
}
这可能导致的一个问题就是，我们可以拿着wechat的code，去找GitHub换access token，而很显然这个兑换通常会失败，导致无法登录。
那这个问题严重吗？
一般来说，比如我这个网站固定了比如说只允许用QQ，WeChat，微博登录。这种问题，通常只会导致有些时候登录失败。换个说法是，测试工程师应该会先发现这个`bug`。
如果说完全没有安全问题也不一定。
当客户端同时对接多个授权服务器，且其中至少有一个授权服务器恶意、被攻陷，或者客户端接受了攻击者控制的注册/元数据时，未校验 issuer/provider 的实现可能使客户端把授权凭证或后续请求发往错误端点，从而形成真正的 mix-up 安全风险。
但如上面说的样子，这种情况发生的场景非常严苛，罕见。我感觉有些时候，可能会出现在一些自定义的统一认证登录这种场景下。总之不是一个容易发生的攻击。且有可能会先被测开找出来修掉。
这属于，看见了必须要修，但是未必是我们先找到的问题。
🤔 **那OIDC又有什么不同呢？**
我们再来看在OIDC之下小明同学的登录，
- 小明在网站 A 的客户端页面上，选择“使用 Google/微信/企业 SSO 登录”，随后跳转到身份提供方（Identity Provider，IdP）的认证页面完成登录与授权。
- 身份提供方完成认证后，会把一个`code`（授权码）返回给网站 A 的回调地址，同时通常还会携带此前生成的 state，用于防止登录 CSRF。
- 网站 A 的后端服务器拿着这个`code`，向身份提供方的token endpoint请求兑换`token`。
- 从这一步开始，一切就有点不同了，OIDC中，服务器不仅会获得`access token`，还会获得`id_token`，有些时候还会获得`refresh_token`。
- 然后网站A会对`id_token`进行验证，验证通过之后，网站A就可以通过`id_token`提供的用户身份来确认当前登录的用户是谁。
- 接下来，网站 A 通常仍会向用户签发自己系统内部的 Session Cookie 或 JWT，用于维持自身业务系统的登录态。
那问题来了`id_token`具体是什么？它通常是一个JWT，会包括
sub：用户唯一身份标识（subject），用于确定需要登录的用户究竟是谁
iss：token签发者（issuer）
aud：token 的目标客户端（这个例子中就是A网站，不能拿着签发给A网站的token去登录B网站）
exp：过期时间
iat：签发时间
nonce：用于防止重放攻击
那么其实关于id_token，其实和JWT的验证流程就比较相似了。
- 验签：校验 id_token 的签名是否合法，确认内容没有被篡改
- 校验 iat、exp 等时间字段，确认 token 未过期、未失效
- 校验 iss（issuer），确认 token 确实来自预期的身份提供方
- 校验 aud（audience），确认这个 token 的目标客户端确实是自己
- 校验 nonce，防止登录流程中的重放攻击
- 在上述校验全部通过后，客户端才会信任其中的 sub（subject，用户唯一身份标识），并将其视为“当前登录用户”的身份依据
从代码审计的角度看来，这一步需要注意和JWT需要注意的东西，不能够漏掉，具体参见3.3.1 JWT 的部分
那`nonce`究竟是什么呢？这个部分是需要客户端来处理，具体而言：
- 客户端需要生成一个高熵的`nonce`参数，随着认证请求发送
- 认证服务提供方，如果收到有`nonce`，则需要在后续发回的`id_token`里面附带上`nonce`。
- 客户端检验`nonce`，需要和自己发出的`nonce`进行对比，看是否匹配。检验通过之后，还需要立即删除或者比较已使用（防止被重放）
下面给出一段在spring security之中的写法
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/login**", "/oauth2/**", "/error").permitAll()
.anyRequest().authenticated()
)
.oauth2Login(oauth2 -> oauth2
.loginPage("/login") // 自定义登录页面
.defaultSuccessUrl("/home", true) // 认证成功默认跳转
// 注意：这里完全不设置 .successHandler()
// 也不设置 .userInfoEndpoint() 的自定义服务
)
.oauth2ResourceServer(oauth2 -> oauth2
.jwt(jwt -> jwt.jwtAuthenticationConverter(jwtAuthenticationConverter()))
)
.csrf(csrf -> csrf.disable()) // 根据实际场景评估
.sessionManagement(session -> session
.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
);
return http.build();
}
}
好消息是，Spring Security 会完整保留默认处理链（包括 nonce 校验、UserService 加载、SavedRequest 处理等）。这是否意味着这个地方不需要额外的安全审计了？
坏消息是，那是使用最基础的默认情况的用例。通常情况下，因为业务逻辑的不同，是需要进行一定的自定义的（尤其是.successHandler()），于是会出现覆盖掉框架逻辑的情况，而这个时候如果不进行正确地的继承和补充，就会出现，以为安全了，实际不安全的问题。
错误示例
.oauth2Login(oauth2 -> oauth2
.loginPage("/login")
.defaultSuccessUrl("/home", true) // 这行实际被覆盖，无效
.successHandler((req, res, auth) -> { // 【核心错误点】
OidcUser user = (OidcUser) auth.getPrincipal();
saveUserToDatabase(user); // 直接业务操作
res.sendRedirect("/home"); // 直接跳转
})
.failureHandler(customFailureHandler())
)
在这个例子中，.successHandler 使用 Lambda：完全替换默认处理器，没有继承任何框架实现。后续的安全逻辑就可能会被绕过。
正确的例子
.oauth2Login(oauth2 -> oauth2
.loginPage("/login")
.defaultSuccessUrl("/home", true)
.userInfoEndpoint(userInfo -> userInfo
.oidcUserService(customOidcUserService()) // 优先在这里扩展
)
.successHandler(customOidcSuccessHandler()) // 使用继承方式
.failureHandler(customFailureHandler())
)
@Component
public class CustomOidcSuccessHandler extends SavedRequestAwareAuthenticationSuccessHandler {
private final UserService userService;
public CustomOidcSuccessHandler(UserService userService) {
this.userService = userService;
setDefaultTargetUrl("/home");
setAlwaysUseDefaultTargetUrl(true);
}
@Override
public void onAuthenticationSuccess(HttpServletRequest request,
HttpServletResponse response,
Authentication authentication)
throws IOException, ServletException {
// 【关键：必须先调用 super，保留框架全部后置逻辑】
super.onAuthenticationSuccess(request, response, authentication);
// 再执行自定义业务
OidcUser oidcUser = (OidcUser) authentication.getPrincipal();
userService.saveOrUpdateUser(oidcUser);
}
}
@Bean
public OAuth2UserService customOidcUserService() {
OidcUserService delegate = new OidcUserService();
return userRequest -> {
OidcUser oidcUser = delegate.loadUser(userRequest); // 先走默认（含 nonce 校验）
// 安全扩展自定义逻辑
Set authorities = new HashSet<>(oidcUser.getAuthorities());
authorities.add(new SimpleGrantedAuthority("ROLE_USER"));
return new DefaultOidcUser(authorities, oidcUser.getIdToken(), oidcUser.getUserInfo());
};
}
为什么这样更安全？逻辑是什么？
因为在
.userInfoEndpoint(userInfo -> userInfo
.oidcUserService(customOidcUserService()) // 优先在这里扩展
)
之中的`customOidcUserService()`通常会先调用`delegate.loadUser(userRequest)`（即 Spring Security 默认的 OidcUserService）。这就确保了 nonce 校验（防止重放攻击）、state 参数验证、Token 完整性检查、UserInfo 获取等 OIDC 协议层面的安全机制在自定义逻辑之前就已经完成。
而后面的`.successHandler(customOidcSuccessHandler()) `，`CustomOidcSuccessHandler `继承了`SavedRequestAwareAuthenticationSuccessHandler`的所有能力，包括 SavedRequest 处理、SecurityContext 持久化、默认重定向逻辑等。并通过super调用来完整执行。它会执行认证成功后的标准化处理，确保 nonce/state 等前面已完成的校验真正“落地”，同时处理 Session、安全上下文和跳转等。
这样一前一后，实际上就完整地继承了spring security框架原本默认执行地安全机制。
当然，生产环境之下更加安全的做法可能还要考虑几个问题：
- 虽说正确配置的spring security确实能够自动校验`nonce`，但是通常来说还是需要做显示校验进行加固。原因有二：
- 1.默认配置的方案，在分布式系统的情况下，可能会出现`nonce`对不上的问题，导致这个机制实际上是失效的。尤其无 session 亲和性或使用 Redis 共享存储时。
- 2.日志和后台监控上，有些时候是需要记录一下校验情况的，当然不要把校验过程中的敏感信息打印到log
- SuccessHandler 中的业务逻辑放置：自定义 CustomOidcSuccessHandler 中，业务操作必须放在 super.onAuthenticationSuccess() 之后。
- super 调用会完成框架的 SavedRequest 处理、SecurityContext 持久化、重定向等收尾工作。
- 如果把保存用户到 DB 等敏感/耗时操作放在 super 之前，一旦业务抛出异常，框架清理流程可能未执行，导致状态不一致或安全上下文丢失。
- 推荐顺序：super 先执行 → 再执行业务逻辑 → 必要时捕获异常并做降级处理（不影响用户跳转）。
除此之外，还有：
##### 第二关：application.yaml的配置问题
spring:
security:
oauth2:
client:
registration:
keycloak:
client-id: xxx
client-secret: xxx
authorization-grant-type: authorization_code
redirect-uri: "{baseUrl}/login/oauth2/code/keycloak"
scope: profile, email # 误用：缺少 openid
# redirect-uri 可能写成通配符或未注册
比如没有配置openid scope，这种情况下也能够正常跑，但是会降级到普通的OAuth2，导致nonce机制失效，增加重复风险。
##### 第三关：Session与Token存储不当
在无状态或 SPA 场景下仍依赖默认 HttpSession 存储 nonce/token。
// 误用示例（配置 + 代码）
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.sessionManagement(session -> session
.sessionCreationPolicy(SessionCreationPolicy.STATELESS) // 误用：无状态却依赖 session nonce
)
.oauth2Login(...) // 默认使用 HttpSession 存储 nonce
;
return http.build();
}
// 另外可能出现的误用：前端直接处理 Token
// 在 Controller 或前端代码中：
@PostMapping("/callback")
public void handleCallback(@RequestBody String idToken) {
// 直接存 localStorage 或 cookie
storeInCookie(idToken); // 高危：扩大重放窗口
}
这种情况下：STATELESS 策略下 nonce 无法持久化，导致验证失败或被绕过；Token 明文持久化扩大攻击面。
#### 3.3.6 补充1：Remember-Me
RememberMe是什么？举个例子来说，小明同学登录了A网站，在登录时选择了“记住我”，于是后续一个月的时间里，小明同学访问A网站就不需要登录了。
🤔 嗯，这怎么听起来和JWT或者sessionID很像？
其实本质上目的和作用是不一样的，JWT服务于一种场景，我们想象一个网站，小明需要登录才能够访问home页面和settings页面。
小明同学做了一次登录访问了home页面之后，又想要访问settings页面。如果这个时候系统没有什么机制来记录小明同学的登录状态，那么小明同学就需要再次输入密码进行登录。紧接着小明同学还想访问blog页面，article页面,commments页面……每访问一个页面都需要做一次登录。小明同学抓狂了。
而像JWT和sessionID就是服务于类似的场景的，它们告诉小明同学，你不需要输入密码了，（无感）验证我们就行了。就像给小明贴了一个有时限的，临时的门禁卡，小明走到门禁的地方就会自动验证一下（拦截器），而小明本人只需要走过去，什么都不用做了。
但是这张门禁卡为了安全考虑，是有失效时间的，通常还不能太长（几十分钟到几个小时，时间过长会增大重放风险）。但是小明同学还是不太满意，他想这个小区是我家啊，我天天回家我还需要天天输入密码登记吗？
于是他勾选了一个“记住我”，系统给他发了一个`Remember-Me token`，每次他过门禁的时候，系统先检测他的门禁卡（比如JWT,sessionID）,如果还有效直接放行，如果失效了，就看有没有`Remember-Me token`，如果有，就认为他是小区的合法业主，（无感地）给他换一个新的门禁卡（一个新的JWT,sessionID等）。
这更像是一种机制。
Remember-Me的常规实现。
在传统web应用中通常是
sessionID + remember-me cookie
像前后端分离的应用
access token + refresh token
这里先给出一段spring security之中的例子
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
SecurityFilterChain securityFilterChain(
HttpSecurity http,
PersistentTokenRepository tokenRepository,
UserDetailsService userDetailsService
) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/login", "/css/**", "/js/**").permitAll()
.anyRequest().authenticated()
)
.formLogin(form -> form
.loginPage("/login")
.permitAll()
)
.rememberMe(remember -> remember
.rememberMeParameter("remember-me")
.rememberMeCookieName("remember-me")
.tokenRepository(tokenRepository)
.userDetailsService(userDetailsService)
.tokenValiditySeconds(60 * 60 * 24 * 30)
.key("a-very-long-random-secret-from-env")
)
.logout(logout -> logout
.deleteCookies("JSESSIONID", "remember-me")
.permitAll()
);
return http.build();
}
@Bean
PersistentTokenRepository persistentTokenRepository(DataSource dataSource) {
JdbcTokenRepositoryImpl repository = new JdbcTokenRepositoryImpl();
repository.setDataSource(dataSource);
return repository;
}
}
配套的表单
create table persistent_logins (
username varchar(64) not null,
series varchar(64) primary key,
token varchar(64) not null,
last_used timestamp not null
);
我们观察这个代码，一些基础的问题很显然
1. 有没有硬编码key,有没有用很简单的key：`.key("a-very-long-random-secret-from-env")`
2. 看application.yaml之中的配置，有没有针对cookie的csrf安全防护，比如samesite,httponly,Secure,Path,Max-Age / Expires,Domain
3. token常见的有效期问题，虽说要rememberMe，但是通常没有必要rememberMe一年，对吧？普通的系统，一般是7天，14天，30天。
//危险的配置
.tokenValiditySeconds(Integer.MAX_VALUE)
.tokenValiditySeconds(60 * 60 * 24 * 365)
.tokenValiditySeconds(-1)
4. token常见的注销问题，如果rememberMe在用户选择注销登录时，没有同步注销/清理，下次访问依旧会免登录。一些开发者可能会记得注销JWT/sessionID，但是可能会忘记rememberMe。当然，也不排除都忘记了的可能。
.logout(logout -> logout
.deleteCookies("JSESSIONID", "remember-me")
.permitAll()
5. 是否使用了简单 Hash-Based Remember-Me，通常推荐的是persistent token remember-me。像这种简单Hash-Based rememberMe最大的问题就是，服务端不会保存token状态。因此只会判定是否过期了，无法主动拉黑或者注销某个token。在这种情况下，如果一个token泄露了，在这个token失效前，我们大概率对它无计可施。
base64(username:expirationTime:algorithmName:signature)
.rememberMe(remember -> remember
.key("mySecret")
.tokenValiditySeconds(60 * 60 * 24 * 30)
)
6. 像token这个东西，通常也不建议明文保存，一般认为只保存`token hash`这个东西更加合适
create table persistent_logins (
username varchar(64) not null,
series varchar(64) primary key,
token varchar(64) not null,
last_used timestamp not null
);
7. 自研 Remember-Me 是否把敏感信息放进 Cookie，比如：
Cookie cookie = new Cookie("remember-me", userId + ":" + password);
一个误区是，`token`是加密的，放点敏感信息问题也不大。但问题在于，很多`token`算法本身并不是加密的。这个地方需要强调的是rememberMe更像是一种机制，不是一种`token`算法本身。这个`token`究竟是不是加密的，要看开发者究竟用了什么算法。比如像下面这些都算不上是加密的`token`：
Base64.getEncoder()
URLDecoder.Eecode
MD5
DigestUtils.md5DigestAsHex
另一点就是，通常不建议信任`token`之中，用户提供的`role`等参数，需要后端再进行查验。
8. 然后是日志不要乱打印`token`这样敏感的参数。
🖊 然后，我们再讨论一些更有趣，更rememberMe本身的场景：
**第一个场景：是否及时吊销了`rememberMe token`**
我们来看这样一个场景。小明同学的A网站账号被小黄同学盗用了，于是，小明同学紧急修改了自己的密码来保护自己的账号。在这个场景下我们需要做点什么。
更新密码，然后吊销之前的`access token`（比如JWT，sessionID）？
这样足够吗？
其实是不够的，我们说过，当系统检测`access token`过期之后，会看有没有`rememberMe token`，如果有的话，就再颁发一个`access token`。小黄同学就可以继续美美地登录了。
更糟糕地是，如果修改密码不需要输入原始密码，小黄同学甚至可以改掉小明同学的密码。
因此，在代码审计的步骤里面，我们要分析这一部分的逻辑：
- 首先，修改代码之前，有没有做验证，比如验证原始密码，或者做邮箱，短信验证等
- 修改了密码后，有没有注销旧得`access token`和`rememberMe token`？
如果使用 Spring Security 默认表：
delete from persistent_logins where username = ?;
延申到其他的场景，比如管理员要暂时封禁一个账户，就不能只拉黑`access_token`，还需要拉黑`rememberMe token`。
总结来说就是：
- 敏感的操作，如修改密码，提现，转账，创建API key等，不能够以`rememberMe`的弱登录为准，要有二次验证
- 需要吊销`access_token`的场景，都需要考虑一下`rememberMe token`是否需要同时吊销了
**第二个场景：随机数是否安全**
为什么随机数很重要？因为作为登录凭证，`rememberMe token`需要不可预测，如果随机数不安全，就会影响到这个不可预测。而攻击者如果通过猜测，遍历得到了某个合法的`token`，很显然就能够用于去登录不属于他的账号。
这个比较危险
Random random = new Random();
UUID.randomUUID(); // 勉强可用但不如 SecureRandom 明确
System.currentTimeMillis();
username + timestamp;
建议使用
SecureRandom secureRandom = new SecureRandom();
byte[] bytes = new byte[32];
secureRandom.nextBytes(bytes);
String token = Base64.getUrlEncoder().withoutPadding().encodeToString(bytes);
在启用spring security的时候，生成随机`token`的过程，是框架自动进行的，默认使用的是`SecureRandom`。在不启用spring security的情况下需要关注这点。
#### 3.3.7 补充2：SSO（Single Sign-On）
这里仅做一个机制的解释，SSO 是一种让用户一次登录后访问多个系统的机制。
在现代系统里，通常会基于 OIDC 来实现。
多个业务系统作为 RP，统一接入同一个 OP/IdP。用户首次访问某个系统时，会通过 OIDC 流程到 IdP 完成认证。认证成功后，IdP 建立自己的登录会话，同时业务系统建立本地会话。
之后用户再访问其他接入同一 IdP 的系统时，这些系统虽然也会发起 OIDC 登录流程，但由于 IdP 已经识别到用户已有会话，所以无需再次输入密码，从而实现单点登录。SSO 本质上依赖的是多个应用对同一个身份源的信任，以及对该身份源会话的复用。
因此SSO实现的究竟安不安全，首先要看是用什么实现的，比如现在常见的OAuth2 / OIDC，老一点系统常用的SAML，CAS，知道了SSO是用什么实现的之后，然后再去看针对于这个机制实现的是否安全。
#### 3.3.8 补充3：Access Token / Refresh Token
前面在 OAuth 2.0 中其实已经讨论过相关内容，这里主要作为一个补充说明。
我们可以把 **Access Token** 和 **Refresh Token** 理解成“两把用途不同的钥匙”。需要注意的是，这里讨论的是一种**令牌协作机制**，而不是某种具体的 `token` 生成算法。换句话说，`access token` 并不等同于某一种固定实现，它既可以是 `session id`，也可以是 `JWT`，或者其他形式的令牌。
- **Access Token**：可以理解为“工作钥匙”，通常是短期有效的，用来访问受保护的 API。
- **Refresh Token**：可以理解为“续期钥匙”，通常有效期更长，用来换取新的 `access token`。
那么，为什么不直接使用一个长期有效的 `access token`，而是要引入这样一套看起来更复杂的机制呢？
原因在于，`access token` 本身往往拥有较强的访问能力。它更像是“金库的钥匙”：一旦泄露，攻击者就可能直接利用它访问受保护资源。如果它还是一个长期有效的令牌，那么风险就会被进一步放大。相反，将 `access token` 设计为短期有效，可以显著缩小风险窗口。这样即使攻击者窃取到了它，也可能很快失效，或者至少无法在较长时间内持续使用。
但这也引出了另一个关键点：**`refresh token` 实际上往往更加敏感。**
因为一旦攻击者获取了 `refresh token`，就可能通过它不断申请新的 `access token`，从而持续维持访问能力。
正因为如此，`refresh token` 在安全模型中的定位，和 `remember-me token` 有一定相似之处：它不仅仅是一个“长期凭证”，还需要随着具体业务逻辑，支持诸如以下能力：
- 吊销（revocation）
- 轮换（rotation）
- 风险审计（risk auditing）
- 设备管理（device management）
在实践中，`refresh token` 通常会被存放在 Cookie 中，并结合如下属性进行保护：
- `HttpOnly`
- `Secure`
- `SameSite`
这也意味着，它需要受到与其他存放在该位置的敏感凭证同等级别的保护。换言之，**不要因为它“不直接访问资源”，就低估它的安全重要性**；从某种意义上说，`refresh token` 往往比 `access token` 更值得谨慎对待。
关于代码方面， Spring 生态已经提供了官方 refresh token 方案，但是否需要你自己写，取决于你是在“做授权服务器”，还是只是“做一个普通登录系统”。
比如以下是一段配置
//授权服务器配置
@Configuration
@EnableWebSecurity
public class AuthorizationServerConfig {
@Bean
@Order(1)
public SecurityFilterChain authorizationServerSecurityFilterChain(HttpSecurity http) throws Exception {
OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http);
return http.build();
}
@Bean
@Order(2)
public SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(authorize -> authorize.anyRequest().authenticated())
.formLogin(Customizer.withDefaults());
return http.build();
}
}
@Bean
public RegisteredClientRepository registeredClientRepository() {
RegisteredClient registeredClient = RegisteredClient.withId(UUID.randomUUID().toString())
.clientId("demo-client")
.clientSecret("{noop}demo-secret")
.clientAuthenticationMethod(ClientAuthenticationMethod.CLIENT_SECRET_BASIC)
.authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
.authorizationGrantType(AuthorizationGrantType.REFRESH_TOKEN)
.redirectUri("http://127.0.0.1:8080/login/oauth2/code/demo-client")
.scope(OidcScopes.OPENID)
.scope("read")
.tokenSettings(TokenSettings.builder()
.accessTokenTimeToLive(Duration.ofMinutes(15))
.refreshTokenTimeToLive(Duration.ofDays(7))
.reuseRefreshTokens(false)
.build())
.build();
return new InMemoryRegisteredClientRepository(registeredClient);
}
这里有 3 个点最重要：
1. `authorizationGrantType(AuthorizationGrantType.REFRESH_TOKEN)`,这表示这个客户端允许使用 refresh token grant。
2. `refreshTokenTimeToLive(Duration.ofDays(7))`,这是`refresh token`的有效期配置。这个能力由 `TokenSettings`提供。这个地方很显然不建议时间配置得过长。
3. `reuseRefreshTokens(false)`,设为`false`表示不复用`refresh token`，也就是每次刷新时都会下发新的 `refresh token`；官方 API 说明写得很明确。默认值是`true`。这个地方建议轮换，更容易防范盗用和重放。
比如repository实现下需要这个类似于样子
@Repository
public class AuthorizationQueryRepository {
private final JdbcTemplate jdbcTemplate;
public AuthorizationQueryRepository(JdbcTemplate jdbcTemplate) {
this.jdbcTemplate = jdbcTemplate;
}
public List findAuthorizationIdsByPrincipalName(String username) {
return jdbcTemplate.query(
"select id from oauth2_authorization where principal_name = ?",
(rs, rowNum) -> rs.getString("id"),
username
);
}
public void deleteById(String id) {
jdbcTemplate.update("delete from oauth2_authorization where id = ?", id);
}
}
#### 3.3.9 补充4：sessionStorage / Cookie /localStorage 区别在哪里？
有这样一个场景，小明同学打开了 A 网站的页面进行浏览，他看中了一个心仪的物品 B，于是需要登录进行购买。小明同学点击登录按钮，完成登录后顺利下单，然后继续保持登录状态浏览 A 网站，并在页面之间不断跳转。一切看起来都很正常。
紧接着，小明同学又看上了物品 C 和 D。为了方便对比，他在原来的 Tab 中打开了 C，又新开了一个 Tab 打开 D 进行比较。比对之后，小明决定购买 D。
结果，当他准备付款时，却发现自己竟然没有登录，需要重新登录一次！
恼羞成怒的小明索性关闭了整个浏览器，再重新打开 A 网站。结果这一次，他彻底退出了登录，需要重新登录。
为什么会这样？
原因就在于：网站的“登录状态”通常会被保存在浏览器中的某个存储区域，而不同存储方式的生命周期和作用范围并不一样。
通常来说，登录状态可能被保存在下面三种地方：
- Cookies：浏览器会自动在请求中携带
- localStorage：浏览器提供的持久化本地存储
- sessionStorage：浏览器提供的会话级本地存储（仅当前 Tab 有效），有时会被塞在前端隐藏的表单里（过时的方案）
另外，这里要区分一下 sessionStorage 和 Session Cookie：
- Session Cookie依旧是放在Cookie里面的，只是这个Cookie通常策略是不持久化存储，关闭浏览器就会失效。
- sessionStorage存放地点，需要看情况，有浏览器保持的，有前端保持的，关闭Tab就会失效。
那么小明同学遇到的这种情况，其实就是sessionStorage的存储方式，登录状态只在当前tab下有效。
这种用法说新不新，说旧不旧。主要是在有一段时间里，对一些旧系统进行改造，比如做前后端分离时，一定程度上为了兼容，为了工程效率采用的方案。后面并没有广泛被使用的原因很显然，不是很合适目前微服务的框架 ，不是很方便，toC情况下用户会很烦。当然也不是完全没有应用场景的，比如一些安全要求严格的场景，如果确实希望仅在单个tab下保持登录状态，关闭就要重新登陆，也不是不可以。
当然除了很不好用，我们其实更加关注的是安不安全。
| 特性 | Cookie | localStorage | sessionStorage |
| -------- | ---------------- | ------------ | -------------- |
| 自动随请求发送 | √ | × | × |
| 服务端可读 | √ | × | × |
| 前端 JS 可读 | 部分可（HttpOnly 不可） | √ | √ |
| 多 Tab 共享 | √ | √ | × |
| 浏览器关闭后保留 | 可配置 | √ | × |
| 适合登录态 | √ 最常见 | ⚠️ 有风险 | × 不适合 |
|
由此我们可以去理解，有些时候不是说某种token算法带来的风险（由算法带来的，很多时候是密码学层面的问题），而是：
- 这个 Token 被存放在什么地方
- 浏览器会如何处理它
- 它会以什么机制参与请求
也就是说：“Token 的安全性” 很大程度上取决于 “存储介质的行为”。
如果把JWT放在Cookie里面，那么JWT就是Cookie，会被浏览器自动携带着，就会有CSRF风险。
Set-Cookie: token=jwt_xxx
把SessionID放在localStorage，那么浏览器就不会自动携带它，它某种意义上就不算是“Cookies”，CSRF风险减小了。
localStorage.setItem("token", jwt)
但是对应的，既然你不让浏览器自己带，那你只能够自己携带，自己携带的话，那得用JS操作吧？
fetch(url, {
headers: {
Authorization: `Bearer ${token}`
}
})
能够用JS读，是不是就至少给了有XSS的可能？
因此在安全审计时，我们真正需要理解的是：
- 开发者想实现的认证模型是什么
- 他们以为自己在用什么
- 实际上浏览器又会如何处理
比较恐怖的场景是，开发者不知道自己想要的是哪种安全机制，实现了一个原理他们不够清楚的安全机制，然后不知道浏览器后面会做什么……理论上来说，在有严格开发规范的公司里，这样的事情出现概率低。值得担忧的是小企业，或者小项目外包的场景。
比如一些糟糕的情景：
- 明明用的是JWT，想用的也是JWT，结果塞到Cookie里面去了，然后又没有做对应的CSRF防护措施，以为JWT本身是防CSRF的。
- 或者，为防CSRF，把cookie/sessionID放到了localStorage里面去，同时认为cookie/sessionID不需要防护XSS。于是攻击者直接`localStorage.getItem("token")`
基于这个，我们再来分析几个现代主流的做法。
第一个是一个早一点的做法，也就是我们常说的`csrf token`，现在很多面经里面依旧还是采用的一种说法。
比如在cookie场景之下，在前端页面塞一个`csrf token`在隐藏的表单里面，后面发送请求时通过前端页面来携带这个`csrf token`。例如：
在典型 CSRF 场景下，攻击者虽然能诱导用户发请求，但无法读取受害网站的页面内容。也就是说：攻击者可以“让浏览器发请求”，但无法知道真正的`csrf token`是什么。因此即使浏览器自动带上了认证 Cookie,攻击者也没法同时伪造`csrf_token`。
不过：“把 CSRF Token 塞进页面里” 本身也不是唯一方案。
后来逐渐流行起另一种更现代的做法：Double Submit Cookie（双重提交 Cookie）
它的核心思路是：
- 一个 Cookie 用于认证（通常是 HttpOnly）
- 另一个 Cookie 用于保存 CSRF Token（通常不给 HttpOnly）
例如：
Set-Cookie: sessionid=xxx; HttpOnly
Set-Cookie: csrf_token=abcd
这个地方，`sessionid`，用于认证， JS 不可读（httponly），浏览器自动携带；`csrf_token`，不设置 HttpOnly，JS 可以读取，浏览器同样会自动携带
发送请求时，浏览器会自动带上：
Cookie: sessionid=xxx; csrf_token=abcd
与此同时,前端 JS 再主动读取：
document.cookie
把`csrf_token`再放到：
X-CSRF-Token: abcd
或者：
csrf_token=abcd
服务器收到后，对两个`csrf_token`是否一致进行比对。
这个方案之所以成立在于，在传统的CSRF场景之下，攻击者是无法知道cookie的具体值的，只是利用了浏览器自带的动作。因此在这里也无法伪造由前端 JS 自带的那个`csrf cookies`
PS:补充一点是，很显然这两个方案都有 JS 的操作框架，不会天然地防XSS。
结合起来，我们总结一下，现代完整的登录框架实践比如有
- JWT + HttpOnly Cookie：即把JWT放入Cookie中，同时配置CSRF防护，比如HttpOnly，SameSite，CSRF Token（比如上面所说的两种携带方案），Origin 校验等
- Session + HttpOnly Cookie，同时也要配合上述的防护。
PS：其实不怎么喜欢放在localstorage里面，因为XSS风险更大。而XSS的危害是要大于CSRF的。我们在做代码审计的时候也可以关注，JWT放在cookie里面不一定是错的，注意看有没有对应的防护措施。
### 3.4 数据库与数据安全（DAO层 / Mapper / Repository）
谈到数据库，值得令我们关注的，就是数据库注入问题。我们暂且以三种案例进行讨论：
**（1）MyBatis**
在使用 MyBatis 时，从审计角度来看，应重点关注参数绑定方式：
- `#{}`：表示预编译参数绑定（PreparedStatement），**安全**
- `${}`：表示字符串拼接，**存在 SQL 注入风险**
✅ 正确使用方式：
@Select("SELECT * FROM address_book WHERE id = #{id}")
❌ 错误使用方式：
@Select("SELECT * FROM address_book ORDER BY ${column}")
`${}` 会将参数直接拼接进 SQL，如果参数来源于用户输入，则可能导致 SQL 注入。
一般情况下，项目中应尽量避免使用 `${}`。但需要注意的是，在 `ORDER BY` 场景中：
- 字段名无法使用 `#{}` 绑定
- **只能使用 `${}` 进行拼接**
因此，这种场景应该尤为关注：
- `${}` 的参数是否来源于用户输入
- 是否对字段值做了限制（如白名单）
- 是否存在直接透传参数的情况
安全的使用是（白名单限制）：
public String getOrderByColumn(String column) {
List whitelist = Arrays.asList("id", "name", "create_time");
if (whitelist.contains(column)) {
return column;
}
return "id";
}
@Select("SELECT * FROM address_book ORDER BY ${column}")
List list(@Param("column") String column);
String safeColumn = getOrderByColumn(userInput);
mapper.list(safeColumn);
PS：补充一个后来发现的问题。后来我观察 C# 相关的 SQL 处理时发现，其实也存在同样的问题。
C# 一个很好用的点在于，它的查询通常会比较“自动化”地去做参数化处理。但在 `order by` 场景下，这种机制其实依旧无能为力。
一种常见的解释是：我们无法对 `order by` 后面的参数进行参数化。这个说法没错，但还不算本质。
更本质的原因在于：`order by` 后面的内容，本质上是“列名”。而列名、表名这类结构性标识符，和 `id`、字符串等普通参数不一样，它们本身无法像普通值那样参与预编译（本质上是：SQL 的结构部分无法被参数化绑定）。
好消息是，这类列名通常不太需要用户直接输入，因此真正暴露在用户可控输入中的概率并不算高。
坏消息是，这意味着，这种情况并不只存在于 `order by`。
`order by` 只是一个非常经典、也最容易被注意到的场景，它实际上说明了一件更糟糕的事情：
也就是说，这种“无法预编译”的危险场景，很可能不仅存在于 `order by`，还可能出现在其他需要动态列名、动态表名的地方。
因此，一方面，开发者在编写代码时，如果直接尝试使用 `#{}`（至少在 C# 里）通常会直接报错；
另一方面，当代码中出现 `${列名}` 这种写法时，就必须额外关注：
- 这个列名是否来自用户输入？
- 是否存在用户可控路径？
- 是否做了白名单校验？
- 是否限制了可选字段范围？
因为这类地方，本质上已经脱离了“普通参数化”能够保护的范围。
**(2) Mybatis Plus**
SQL风险相对更少但值得注意：
**① Wrapper 条件拼接不当**
一般情况下，像下面这种写法是安全的：
LambdaQueryWrapper wrapper = new LambdaQueryWrapper<>();
wrapper.eq(User::getId, id);
userMapper.selectList(wrapper);
这是因为`eq()`中的参数会作为预编译参数处理，不会直接拼接进 SQL。
但如果开发者错误地把用户输入当作 SQL 片段使用，就可能出现风险。例如：
QueryWrapper wrapper = new QueryWrapper<>();
wrapper.last("limit " + userInput);
userMapper.selectList(wrapper);
`last()`的内容会被直接拼接到 SQL 语句末尾，不会进行参数预编译。
如果`userInput`可控，则可能带来 SQL 注入问题。
**② 使用`apply()`、`inSql()`、`exists()`等方法时直接拼接参数**
MyBatis Plus 提供了一些用于拼接原生 SQL 片段的方法，这些方法在审计中应重点关注：
- `last()`
- `apply()`
- `inSql()`
- `notInSql()`
- `exists()`
- `notExists()`
例如下面的写法就存在风险：
QueryWrapper wrapper = new QueryWrapper<>();
wrapper.apply("date_format(create_time,'%Y-%m-%d') = '" + userInput + "'");
userMapper.selectList(wrapper);
**③ 动态条件可能带来的逻辑绕过问题**
除了传统意义上的 SQL 注入外，MyBatis Plus 还需要关注一种比较常见的问题：动态条件控制不严，导致查询逻辑被绕过。
LambdaQueryWrapper wrapper = new LambdaQueryWrapper<>();
wrapper.eq(User::getStatus, 1);
if (StringUtils.isNotBlank(name)) {
wrapper.like(User::getName, name);
}
这种写法本身不一定会导致 SQL 注入，但如果业务中过于依赖前端传参控制查询条件，就可能出现：
- 原本应限制的数据范围被放宽
- 某些查询条件缺失后返回全部数据
- 通过构造特殊参数绕过业务过滤逻辑
**④ 与 MyBatis 混用时，手写 SQL 仍然存在 ${} 风险**
这一点参考（1）的部分
**(3) 预编译**
一个误区是使用了预编译就一定没有SQL注入的风险，原因在于一些开发者可能误用预编译，导致为预编译
String sql = "update book set book_id='"+val1+"', "
+ "stock='"+val2+"' where book_id='"+val1+"'";
ps = con.prepareStatement(sql);
在这个案例之中，虽然使用了`prepaStatement`，但是sql语句本身还是拼接的。
安全的使用是
String sql = "select * from student where student_id=?";
try {
ps = con.prepareStatement(sql);
ps.setString(1, txtsid.getText());
rs = ps.executeQuery();
### 3.5 工具类（文件上传 / HTML过滤 / JWT等）
在这一步里，我来举几个开源教学项目之中最常出现的漏洞。分析存在漏洞的写法和安全的写法（或说修复方案）
#### 3.5.1 文件上传
这是一个基于阿里OSS的文件上传工具类，观察这个代码，问题在哪里？
@Data
@AllArgsConstructor
@Slf4j
public class AliOssUtil {
private String endpoint;
private String accessKeyId;
private String accessKeySecret;
private String bucketName;
/**
* 文件上传
*
* @param bytes
* @param objectName
* @return
*/
public String upload(byte[] bytes, String objectName) {
// 创建OSSClient实例。
OSS ossClient = new OSSClientBuilder().build(endpoint, accessKeyId, accessKeySecret);
try {
// 创建PutObject请求。
ossClient.putObject(bucketName, objectName, new ByteArrayInputStream(bytes));
} catch (OSSException oe) {
System.out.println("Caught an OSSException, which means your request made it to OSS, "
+ "but was rejected with an error response for some reason.");
System.out.println("Error Message:" + oe.getErrorMessage());
System.out.println("Error Code:" + oe.getErrorCode());
System.out.println("Request ID:" + oe.getRequestId());
System.out.println("Host ID:" + oe.getHostId());
} catch (ClientException ce) {
System.out.println("Caught an ClientException, which means the client encountered "
+ "a serious internal problem while trying to communicate with OSS, "
+ "such as not being able to access the network.");
System.out.println("Error Message:" + ce.getMessage());
} finally {
if (ossClient != null) {
ossClient.shutdown();
}
}
//文件访问路径规则 https://BucketName.Endpoint/ObjectName
StringBuilder stringBuilder = new StringBuilder("https://");
stringBuilder
.append(bucketName)
.append(".")
.append(endpoint)
.append("/")
.append(objectName);
log.info("文件上传到:{}", stringBuilder.toString());
return stringBuilder.toString();
}
}
很显然，这个工具类仅完成了一件事，就是文件上传。
❓️ 它有没有做什么？
- 判断文件的类型
- 限制文件大小
- 校验文件内容
- 对文件名（objectName）进行过滤或规范化
也就是说，这个工具类本身是一个**纯功能实现**，而不是一个**安全实现**。
🔎 这意味着什么？
如果上层（controller）没有做额外校验，那么用户可以上传任意内容：
- 可执行脚本文件（如 `.jsp`、`.html` 等）
- 带有恶意内容的文件（如 XSS payload）
- 超大文件（造成存储或带宽消耗）
此外，`objectName` 由外部传入且未经过处理，也可能带来一些问题，例如：
- 覆盖已有文件
- 构造特殊路径（如目录穿越风格的命名）
- 通过文件名直接影响访问 URL
**另一个，关键问题是，这个工具类，本身是否有漏洞吗？是否会形成攻击链？**
这取决于后续在controller / service层，它是怎样被提供给用户的。
即后续需要重点关注：
- **什么权限的用户可以调用该功能？**
- 一个比较危险的思路是，将后台操作者默认视为“可信对象”，认为只要工具类不直接暴露给普通用户，即使实现不安全也是可以接受的
- 实际上，即便只对后台开放，这类不安全的工具能力依然应该被修复，因为一旦发生越权或账号被利用，风险会被进一步放大
- **调用处是否进行了文件上传校验？**
- 通常来说，即使在 controller / service 层根据业务需求存在不同的校验逻辑，在 utils 层也应具备一些基础的通用防护（如文件大小限制、文件名规范化等）
- 如果 utils 层完全没有任何限制，那么很可能上层也没有进行严格校验，这种情况需要重点关注
- **上传后的文件是否可以被直接访问？**
- 在一些常见的小项目中（如用户头像、商品图片等场景），上传后的文件往往可以通过 URL 直接访问
- 如果上传内容未经过校验，这将可能导致 XSS，甚至在特定情况下形成进一步的攻击链（如结合前端渲染问题）
❓️ **又一个问题，写了过滤就一定安全吗？**
并非如此。做过渗透的小伙伴会知道，一些文件上传漏洞，恰恰就来源于——**“看起来做了过滤，但实际上过滤不充分”**。
下面是几个常见的错误示例：
**① 只通过后缀判断文件类型**
if (!fileName.endsWith(".jpg")) {
throw new RuntimeException("只允许上传jpg图片");
}
- 可以通过双后缀绕过：`shell.jsp.jpg`
- 或大小写绕过：`shell.JPG`
👉 本质问题：仅依赖字符串判断，不可靠
**② 简单黑名单过滤**
if (fileName.contains(".jsp") || fileName.contains(".php")) {
throw new RuntimeException("非法文件");
}
- 依旧可以绕过：
- `shell.jsp;.jpg`
- `shell.jsp%00.jpg`
- `shell.jsp .jpg`
👉 黑名单永远不完整
**③ 只校验 Content-Type**
if (!file.getContentType().equals("image/jpeg")) {
throw new RuntimeException("只允许上传图片");
}
- Content-Type 可被伪造（例如使用burp suite篡改报文）
- 攻击者可以上传任意文件并伪装为图片
👉 本质：信任客户端数据
**④ 只检查文件头（但不完整）**
byte[] bytes = file.getBytes();
if (bytes[0] != (byte)0xFF || bytes[1] != (byte)0xD8) {
throw new RuntimeException("非法图片");
}
- 只检查前几个字节，可以构造“图片马”
- 后面仍然可以嵌入恶意代码
**⑤ 文件名未规范化**
ossUtil.upload(fileBytes, fileName);
- 攻击者可控 `fileName`
- 可能导致：
- 覆盖文件
- 构造特殊路径
- 注入恶意URL
📚 值得注意的是，大多数初学者自行编写的过滤逻辑往往并不可靠。
在实际开发中，更推荐使用经过验证的成熟安全库来完成相关功能，例如：
- 文件类型检测：
- `Apache Tika`（基于文件内容识别类型）
- `java.nio.file.Files.probeContentType()`
- 文件上传安全处理：
- Spring 提供的 `MultipartFile` 配合服务端校验
- 结合白名单策略（允许的类型、大小等）
在此基础上，仅针对具体业务需求进行必要的定制，而不是从零开始自行实现过滤逻辑。
同时，即使使用成熟库，也应关注其使用方式是否正确，并结合实际场景进行审计。
#### 3.5.2 HTML 过滤工具类
本质上，这一类问题与文件上传类似，甚至可以类比密码算法的设计原则：
👉 **涉及复杂规则的安全处理，应尽量使用经过验证的成熟实现，而不是自行编写（哪怕是AI写也不建议，AI只建议基于专业库写补充规则）。**
在实际项目中，HTML 过滤通常存在以下三种情况：
- **完全没有过滤机制**
- 这种情况下，需要重点关注 controller / service 层是否存在富文本相关功能（如评论、文章等），这些场景是 XSS 的高发区域
- 如果项目中没有涉及富文本，相对问题不大；如果存在，则需要进一步结合前端渲染方式一起分析
- **手写过滤规则**
- 这种情况通常风险较高
- 常见问题包括：规则不完整、正则误用、未考虑绕过方式等
- 在审计时，可以将过滤逻辑交给大模型或工具辅助分析，快速定位潜在绕过点
- **使用专业库或函数**
- 相对安全，但仍需关注是否存在误用
- 例如：配置不当、过滤策略过宽，或与业务逻辑存在冲突
这里我也从简单到复杂，举几个手写HTML过滤规则被绕过的例子
**① 只过滤 `", "");
绕过方式：
问题：
- 大小写绕过
- 只过滤 script，忽略其他可执行标签
**② 使用简单正则删除标签**
content = content.replaceAll("<.*?>", "");
绕过方式：
<
ipt>alert(1)ipt>
问题：
- 正则无法正确解析嵌套HTML结构
- 很容易被构造绕过
**③ 只过滤关键字（黑名单）**
if (content.contains("script")) {
throw new RuntimeException("非法内容");
}
绕过方式：