第22章安全重构

课程目录第22章安全重构

安全重构：OWASP Top 10漏洞修复重构、输入验证重构、认证授权重构、敏感数据保护重构

安全重构，说白了就是在不改动软件功能的前提下，把代码里的安全漏洞一个个堵上。我见过太多团队，功能跑得飞起，结果安全测试一过，满屏的高危漏洞。嗯，这时候再回头改代码，代价就大了。

这一章，我们聚焦四个核心方向：OWASP Top 10漏洞修复、输入验证重构、认证授权重构、敏感数据保护重构。这四个点，基本覆盖了日常开发中80%的安全隐患。

OWASP Top 10漏洞修复重构

OWASP Top 10是安全领域的「必读清单」。我个人习惯，每次做安全重构前，先对照这个清单扫一遍代码。你想想看，如果连Top 10的漏洞都没处理，其他安全措施做得再好也是白搭。

常见的几个高危漏洞及重构策略：

漏洞类型	典型表现	重构策略
注入攻击（SQL、NoSQL、OS）	拼接字符串执行查询	改用参数化查询或ORM框架
失效的身份认证	弱密码、会话固定	引入多因素认证、会话超时机制
敏感数据泄露	明文存储密码、信用卡号	加密存储、脱敏展示
XML外部实体（XXE）	解析XML时未禁用外部实体	禁用DTD、使用JSON替代XML
失效的访问控制	未校验用户权限	统一权限校验中间件

我曾经接手过一个老项目，所有SQL查询都是字符串拼接的。用户输入什么，就直接拼到SQL里。你想想看，这有多危险？一个简单的 ' OR 1=1 -- 就能把整个用户表拖走。重构时，我把所有数据库操作都改成了参数化查询，顺便引入了ORM框架。改完之后，整个团队都松了一口气。

核心原则：永远不要信任用户输入。所有输入都要经过验证、过滤、转义。

输入验证重构

输入验证是安全的第一道防线。我建议，每个接口入口都要做三层验证：

格式验证：检查数据类型、长度、格式是否符合预期
语义验证：检查业务逻辑上是否合理（比如年龄不能是负数）
安全验证：检查是否包含恶意内容（如SQL注入、XSS脚本）

举个例子，一个用户注册接口，原来可能是这样写的：

// 重构前：几乎无验证
public void register(String username, String password) {
    String sql = "INSERT INTO users VALUES ('" + username + "', '" + password + "')";
    execute(sql);
}

重构后，应该变成这样：

// 重构后：多层验证 + 参数化查询
public void register(String username, String password) {
    // 1. 格式验证
    if (username == null || username.length() < 3 || username.length() > 20) {
        throw new IllegalArgumentException("用户名长度需在3-20之间");
    }
    if (!username.matches("^[a-zA-Z0-9_]+$")) {
        throw new IllegalArgumentException("用户名只能包含字母、数字和下划线");
    }
    
    // 2. 语义验证
    if (password.length() < 8) {
        throw new IllegalArgumentException("密码长度不能少于8位");
    }
    
    // 3. 安全验证：参数化查询
    String sql = "INSERT INTO users (username, password) VALUES (?, ?)";
    execute(sql, username, hashPassword(password));
}

我的经验：输入验证不要只做前端校验。前端校验是为了用户体验，后端校验才是真正的安全防线。我曾经见过一个项目，前端做了很严格的校验，后端却几乎没做。结果有人直接调API接口，绕过了前端，数据就乱了。

认证授权重构

认证是「你是谁」，授权是「你能做什么」。这两个概念经常被混淆，但重构时要分开处理。

我建议的认证重构步骤：

密码存储：使用bcrypt或Argon2算法，不要用MD5或SHA-1
会话管理：使用JWT或Session，设置合理的过期时间
多因素认证：对敏感操作（如转账、修改密码）增加二次验证
登录限流：防止暴力破解，同一IP连续失败5次后锁定15分钟

授权重构的核心是「最小权限原则」。每个用户只拥有完成工作所需的最小权限。我习惯用RBAC（基于角色的访问控制）模型来重构：

// 重构前：硬编码权限判断
if (user.getRole().equals("admin")) {
    // 允许操作
}

// 重构后：基于角色的权限校验
@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long userId) {
    // 只有ADMIN角色才能删除用户
}

避坑指南：我曾经犯过一个错误，在授权校验时只检查了「用户是否登录」，没检查「用户是否有权限」。结果一个普通用户通过修改URL参数，就能访问管理员的后台页面。嗯，从那以后，我每个接口都加上了权限注解。

敏感数据保护重构

敏感数据包括密码、信用卡号、身份证号、个人隐私信息等。重构时，要遵循「能加密就加密，能脱敏就脱敏」的原则。

我总结了一个敏感数据保护清单：

传输加密：所有敏感数据必须通过HTTPS传输
存储加密：密码用哈希算法，其他敏感数据用对称加密（如AES-256）
展示脱敏：在日志、前端展示时，对敏感数据做脱敏处理（如手机号显示138****1234）
密钥管理：密钥不要硬编码在代码里，使用密钥管理服务（如AWS KMS、HashiCorp Vault）

举个例子，用户手机号的存储和展示：

// 存储时加密
public void saveUserPhone(Long userId, String phone) {
    String encryptedPhone = encrypt(phone, secretKey);
    userRepository.updatePhone(userId, encryptedPhone);
}

// 展示时脱敏
public String getMaskedPhone(Long userId) {
    String encryptedPhone = userRepository.findPhoneById(userId);
    String decryptedPhone = decrypt(encryptedPhone, secretKey);
    return decryptedPhone.replaceAll("(\\d{3})\\d{4}(\\d{4})", "$1****$2");
}

我的习惯：敏感数据重构时，我会先做一次全量扫描，找出所有可能泄露敏感数据的地方。包括日志文件、数据库备份、API响应、前端页面。有时候，一个不起眼的debug日志，就可能把用户密码给打印出来。

安全重构的知识体系

下面这张图，展示了安全重构的核心逻辑和依赖关系：

安全重构不是一次性的工作，而是一个持续的过程。每次代码变更，都可能引入新的安全漏洞。我建议，把安全重构纳入日常的代码评审中，每次提交代码时，都问自己一个问题：「这段代码有没有安全风险？」

嗯，这一章的内容就到这里。安全重构的核心，其实就是把「安全」变成一种习惯，而不是事后补救。希望这些经验对你有帮助。

📚 课程目录

安全重构：OWASP Top 10漏洞修复重构、输入验证重构、认证授权重构、敏感数据保护重构

OWASP Top 10漏洞修复重构

输入验证重构

认证授权重构

敏感数据保护重构

安全重构的知识体系