SpringBoot+MyBatis登录注册模块的5大安全漏洞与根治方案-平芜编程栈

1. 项目概述：为什么登录注册是Web安全的“第一道防线”？

做Web开发这些年，我经手过不少SpringBoot+MyBatis的项目，发现一个挺有意思的现象：很多团队在开发登录注册功能时，往往把重心放在了用户体验和业务流程上，比如验证码好不好看、注册流程顺不顺畅，却容易忽略底下暗流涌动的安全问题。直到某天被安全扫描工具揪出一堆漏洞，或者更糟——线上真的出了数据泄露事故，大家才开始手忙脚乱地“打补丁”。其实，登录注册模块作为用户进入系统的“大门”，其安全性直接决定了整个应用地基的稳固程度。一个脆弱的登录入口，就像给自家金库装了一扇纸糊的门，攻击者可以轻易地通过SQL注入拿到所有用户数据，或者用撞库手段盗取账号，甚至直接绕过认证逻辑长驱直入。

SpringBoot和MyBatis的组合因其高效、灵活而备受青睐，但这也意味着开发者需要承担更多的安全责任。框架本身不会自动帮你堵上所有漏洞，它提供的是工具和可能性，而如何正确、安全地使用这些工具，完全取决于开发者的意识与实操。我见过太多因为一个配置不当、一处逻辑疏忽导致的严重漏洞。所以，今天我想结合自己踩过的坑和修复过的案例，把这套技术栈下登录注册模块最常见的5个安全漏洞及其根治方案，掰开揉碎了讲清楚。无论你是正在开发第一个SpringBoot项目的新手，还是维护着复杂系统的老手，这些内容都是绕不开的必修课。我们的目标很简单：打造一个既健壮又易用的认证门户，让用户安心，也让自己的代码夜里能睡得着觉。

2. 漏洞一：SQL注入——MyBatis的动态SQL不是“免死金牌”

很多人以为用了MyBatis，尤其是它的XML映射文件，就天然免疫SQL注入了。这是一个非常危险的误解。MyBatis的动态SQL功能（<if>,<choose>,<foreach>等）确实强大，但它只是帮你拼接SQL字符串的工具。如果你在拼接时，将用户输入的数据直接“嵌”入了SQL语句，而没有经过任何处理，那么注入漏洞就产生了。

2.1 漏洞场景还原：一个典型的错误写法

假设我们有一个根据用户名查询用户的登录验证方法，在Mapper接口中这样定义：

User findByUsername(@Param(“username”) String username);

然后在XML中，你可能不经意间写出了这样的语句：

<select id=“findByUsername” resultType=“User”> SELECT * FROM user WHERE username = ‘${username}’ </select>

或者，在注册时检查用户名是否存在，使用了${}进行模糊查询：

<select id=“checkUserExist” resultType=“int”> SELECT COUNT(*) FROM user WHERE username LIKE ‘%${username}%’ </select>

这里的${username}就是罪魁祸首。MyBatis对于${}的处理是直接的字符串替换（Statement），它会将参数值原封不动地拼接到SQL语句中。如果用户输入的username是admin’ OR ‘1’=‘1，那么最终的SQL就会变成：

SELECT * FROM user WHERE username = ‘admin’ OR ‘1’=‘1’

这将导致查询条件永远为真，攻击者可能绕过密码验证直接登录，或者泄露所有用户信息。

2.2 修复方案：坚持使用#{}预编译占位符

根本的修复方法极其简单，就是把${}全部替换为#{}。#{}是MyBatis的预编译占位符（PreparedStatement），它会将参数作为一个整体传递给数据库驱动，由驱动进行转义和安全处理，从根本上杜绝了SQL注入的可能性。

正确的写法应该是：

<select id=“findByUsername” resultType=“User”> SELECT * FROM user WHERE username = #{username} </select>

对于模糊查询，正确的做法不是在XML里拼接%，而是在Java代码中处理好再传入：

// Service层代码 public boolean checkUserExist(String username) { String searchKey = “%” + username + “%”; // 在业务层拼接通配符 return userMapper.checkUserExist(searchKey) > 0; }

<!-- XML中依然使用#{} --> <select id=“checkUserExist” resultType=“int”> SELECT COUNT(*) FROM user WHERE username LIKE #{usernamePattern} </select>

注意：有一种罕见但确实存在的场景需要使用${}，那就是动态指定表名或列名（例如，根据参数动态查询不同的表）。在这种情况下，绝对不能接受用户输入作为表名或列名。必须通过白名单机制进行严格校验。例如，定义一个允许的表名集合，只有参数值在这个集合内时才进行拼接，否则抛出异常。

2.3 深度排查与加固建议

仅仅修改写法还不够，我们需要建立一套防止此类错误再次发生的机制。

代码扫描与规约：在团队中强制推行代码规范，禁止在MyBatis XML中使用${}进行值传递。可以利用SonarQube、Alibaba Java Coding Guidelines等代码扫描工具，将${}在WHERE、VALUES等子句中的使用设置为高危规则。
Mapper层代码审查：在代码审查（Code Review）环节，将Mapper XML文件作为重点审查对象，特别是涉及用户输入参数的查询语句。
使用MyBatis-Plus等增强工具：MyBatis-Plus提供的QueryWrapper等条件构造器，其内部生成的SQL默认使用的是预编译方式，能进一步降低手写SQL出错的风险。但切记，即使使用Wrapper，也不要通过字符串拼接的方式设置条件值。

这个漏洞的修复看似简单，却需要开发者从意识上彻底理解#{}与${}的本质区别，并在团队流程中形成肌肉记忆。

3. 漏洞二：密码明文存储与弱加密——用户的“命门”裸奔

这是最触目惊心也最不该发生的漏洞之一。我曾在一次内部审计中，发现一个老项目的用户表里，密码字段赫然以明文形式存储着“123456”、“admin”等字符串。这意味着一旦数据库被拖库（数据被整体窃取），所有用户的账号等同于拱手送人。即使进行了加密，如果使用的是MD5、SHA-1这类已被证明可快速碰撞破解的哈希算法，或者没有加盐（Salt），风险依然极高。

3.1 漏洞危害分析

明文存储：数据库泄露即等于所有账号密码泄露。攻击者可以直接登录，无任何技术门槛。
弱哈希（无盐）：攻击者可以使用彩虹表（预先计算好的哈希值对照表）进行反向查询，快速破解常用密码。同一个密码，其哈希值在所有用户中都是一样的，攻击者破解一个就等于破解了所有使用该密码的账户。
弱哈希（有盐但算法弱）：像MD5、SHA-1这样的算法，其计算速度很快，这使得攻击者可以进行大规模的暴力破解（每秒数十亿次尝试）。即使加了盐，也只是增加了彩虹表攻击的难度，无法抵御针对单个哈希的暴力破解。

3.2 修复方案：采用BCrypt或Argon2进行自适应哈希

当前业界公认最安全的密码存储方案是使用自适应哈希函数，如BCrypt、SCrypt或Argon2。Spring Security Crypto模块已经为我们提供了现成的、易于使用的BCrypt实现。

核心操作步骤如下：

引入依赖：在pom.xml中添加Spring Security Crypto的依赖（通常Spring Boot Starter Security已包含）。

<dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-crypto</artifactId> </dependency>

配置密码编码器：在配置类中声明一个BCryptPasswordEncoderBean。

@Configuration public class SecurityConfig { @Bean public PasswordEncoder passwordEncoder() { // strength代表加密强度，默认10，值越大越安全但耗时越长（4-31之间） return new BCryptPasswordEncoder(12); } }

注册时加密密码：在用户注册的服务逻辑中，使用PasswordEncoder对明文密码进行加密后再存入数据库。

@Service @RequiredArgsConstructor // 使用Lombok注入 public class UserService { private final UserMapper userMapper; private final PasswordEncoder passwordEncoder; public void register(UserRegisterDTO dto) { // ... 其他校验逻辑 ... User user = new User(); user.setUsername(dto.getUsername()); // 关键步骤：加密密码 String encodedPassword = passwordEncoder.encode(dto.getPassword()); user.setPassword(encodedPassword); userMapper.insert(user); } }

加密后的字符串类似于：$2a$12$SomeRandomSaltValue...HashedPasswordPart，其中包含了算法版本、成本因子和盐值。

登录时验证密码：在登录验证时，使用PasswordEncoder.matches()方法比对用户输入的明文密码和数据库中存储的哈希值。

@Service public class AuthService { public boolean login(String username, String rawPassword) { User user = userMapper.findByUsername(username); if (user == null) { return false; } // 关键步骤：验证密码。无需自己处理盐，编码器会从存储的哈希值中提取。 return passwordEncoder.matches(rawPassword, user.getPassword()); } }

3.3 实操心得与进阶考量

成本因子（Strength）的选择：BCryptPasswordEncoder(12)中的12是成本因子。这个值每增加1，计算时间大约翻一倍。建议在生产环境中使用10-12，在保证安全性的同时，不会对登录响应时间造成明显影响（通常仍在100-500毫秒内）。可以通过压测找到一个业务可接受的平衡点。
密码策略：除了加密，强制用户使用强密码是另一道防线。可以在后端校验密码长度、复杂度（包含大小写字母、数字、特殊字符），并拒绝常见弱密码（如123456,password,qwerty等）。可以使用Passay或OWASP Java Password Validation这类库来简化实现。
哈希值存储字段：确保数据库表中密码字段的类型和长度足够容纳BCrypt哈希值（通常60个字符以上，varchar(100)是个安全的选择）。

将用户的密码安全地保管好，是开发者最基本的职业道德和技术底线。BCrypt这类自适应哈希算法，通过内置的盐和可调节的计算成本，使得大规模破解在理论上和实践中都变得极其困难，是目前应对密码存储挑战的最佳实践。

4. 漏洞三：会话固定与会话劫持——你的登录状态可能被“冒名顶替”

用户登录成功后，服务端会创建一个会话（Session），并给浏览器一个唯一的会话标识（通常是JSESSIONID Cookie）。如果这个会话标识的生成、传递或管理过程存在缺陷，攻击者就能窃取或强制用户使用一个已知的会话ID，从而冒充该用户身份。这就是会话固定（Session Fixation）和会话劫持（Session Hijacking）攻击。

4.1 漏洞原理与攻击路径

会话固定攻击：
- 攻击者先访问网站，获得一个合法的会话ID（SID）。
- 攻击者通过某种方式（如构造一个包含该SID的链接发给受害者）诱使受害者使用这个特定的SID登录系统。
- 受害者使用这个SID成功登录后，该会话就被提升为已认证状态。
- 由于攻击者知道这个SID，他就可以直接用这个SID访问网站，以受害者的身份进行操作。
会话劫持攻击：
- 主要发生在会话ID传输过程中被窃取。如果网站没有使用HTTPS，会话ID在网络上明文传输，攻击者通过监听网络流量（中间人攻击）即可获取。
- 即使使用了HTTPS，如果应用存在跨站脚本（XSS）漏洞，攻击者可以通过注入的恶意脚本（如document.cookie）窃取到存储在Cookie中的会话ID。

4.2 修复方案：综合防御策略

修复此漏洞需要一个组合拳，而不是单一措施。

4.2.1 强制使用HTTPS这是最基本也是最重要的要求。HTTPS对通信链路进行加密，可以有效防止网络嗅探导致的会话ID被盗。在Spring Boot中配置HTTPS非常简单，同时你应该配置HTTP到HTTPS的重定向。

# application.yml server: port: 8443 ssl: key-store: classpath:keystore.p12 key-store-password: your-password key-store-type: PKCS12 key-alias: tomcat

此外，可以通过配置确保Session Cookie被标记为Secure，使其只能通过HTTPS传输。

@Configuration public class ServletConfig { @Bean public ServletWebServerFactory servletContainer() { TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory(); tomcat.addContextCustomizers(context -> { // 设置Session Cookie为Secure和HttpOnly context.setSessionCookieName(“JSESSIONID”); context.setSessionCookiePath(“/”); context.setUseHttpOnly(true); context.setSessionCookieHttpOnly(true); context.setSessionCookieSecure(true); // 仅HTTPS传输 }); return tomcat; } }

4.2.2 登录后重置会话ID这是防御会话固定攻击最有效的手段。在用户认证成功的那一刻，立即让旧的会话失效，并创建一个全新的会话。

@Service public class AuthService { public boolean login(HttpServletRequest request, String username, String password) { // ... 密码验证逻辑 ... if (passwordValid) { // 使旧会话无效化 HttpSession oldSession = request.getSession(false); if (oldSession != null) { oldSession.invalidate(); } // 创建新会话 HttpSession newSession = request.getSession(true); newSession.setAttribute(“USER”, user); // 可以在这里设置一些会话属性，如登录时间、IP等 return true; } return false; } }

Spring Security在默认配置下，formLogin()登录成功后会自动执行会话固定保护（sessionFixation().changeSessionId()或migrateSession()），为我们省去了手动实现的麻烦。

4.2.3 设置HttpOnly和SameSite Cookie属性

HttpOnly：防止JavaScript通过document.cookie访问会话Cookie，有效缓解XSS攻击后的会话窃取。Spring Boot默认的Session Cookie就是HttpOnly的。
SameSite：可以设置为Strict或Lax，能很好地防御跨站请求伪造（CSRF）攻击，并对某些类型的会话固定攻击有抑制作用。可以通过Servlet容器配置或过滤器来设置。

4.2.4 绑定会话与客户端特征这是一种增强措施，将会话与客户端的某些特征（如IP地址、User-Agent）进行绑定。当检测到特征变化时（例如登录后IP从北京跳转到国外），要求重新认证。但这可能会误伤使用动态IP或切换网络的正常用户，需要谨慎权衡。

// 在登录成功后，将IP等信息存入Session String clientIp = request.getRemoteAddr(); String userAgent = request.getHeader(“User-Agent”); newSession.setAttribute(“LOGIN_IP”, clientIp); newSession.setAttribute(“USER_AGENT”, userAgent); // 在后续请求的过滤器中校验 public class SessionCheckFilter implements Filter { @Override public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpSession session = request.getSession(false); if (session != null && session.getAttribute(“USER”) != null) { String savedIp = (String) session.getAttribute(“LOGIN_IP”); String currentIp = request.getRemoteAddr(); if (!StringUtils.equals(savedIp, currentIp)) { // IP发生变化，可以记录日志、强制下线或要求二次验证 session.invalidate(); ((HttpServletResponse)res).sendRedirect(“/login?error=session_invalid”); return; } } chain.doFilter(req, res); } }

会话安全是一个持续对抗的过程。通过HTTPS加密传输、登录重置会话、加固Cookie属性这三板斧，能构建起一道坚实的防线，再辅以客户端特征绑定等增强手段，可以极大提升攻击者劫持会话的难度。

5. 漏洞四：暴力破解与撞库攻击——如何让“猜密码”变得徒劳？

登录接口如果没有任何防护措施，就会暴露在暴力破解和撞库攻击之下。攻击者使用自动化工具，以极高的频率尝试不同的用户名/密码组合，直到成功为止。撞库攻击则是利用从其他网站泄露的账号密码库，来尝试登录你的系统，因为很多用户在不同网站使用相同的密码。

5.1 攻击特征与检测难点

这类攻击通常表现为：在短时间内，从同一个IP或针对同一个账号，产生大量失败的登录请求。传统的仅在登录逻辑里判断“用户名或密码错误”的做法，完全无法抵御这种自动化攻击。

5.2 修复方案：多层次速率限制与智能风控

单一的防御措施效果有限，我们需要构建一个从应用到基础设施的立体防御体系。

5.2.1 应用层限流（Rate Limiting）这是最直接的防御手段。我们可以针对登录接口，实施基于IP和用户名的速率限制。

使用Spring Boot整合Redis实现：利用Redis的高性能和过期特性，非常适合做计数器。

@Service public class LoginRateLimitService { @Autowired private RedisTemplate<String, String> redisTemplate; private static final String PREFIX_IP = “login:ip:”; private static final String PREFIX_USER = “login:user:”; private static final int MAX_ATTEMPTS_IP = 20; // 单个IP每5分钟最多尝试20次 private static final int MAX_ATTEMPTS_USER = 5; // 单个账号每5分钟最多失败5次 private static final int TIME_WINDOW = 300; // 时间窗口5分钟（秒） public boolean isIpAllowed(String ip) { return checkAndIncrement(PREFIX_IP + ip, MAX_ATTEMPTS_IP); } public boolean isUserAllowed(String username) { return checkAndIncrement(PREFIX_USER + username, MAX_ATTEMPTS_USER); } private boolean checkAndIncrement(String key, int maxAttempts) { Long count = redisTemplate.opsForValue().increment(key, 1); if (count != null && count == 1) { // 第一次设置，同时设置过期时间 redisTemplate.expire(key, TIME_WINDOW, TimeUnit.SECONDS); } return count != null && count <= maxAttempts; } public void resetAttempts(String ip, String username) { redisTemplate.delete(PREFIX_IP + ip); redisTemplate.delete(PREFIX_USER + username); } }

在登录逻辑中，先调用isIpAllowed和isUserAllowed进行检查，如果任意一个超过阈值，直接返回“尝试次数过多，请稍后再试”的错误，并记录日志。登录成功后，调用resetAttempts清除计数。

使用Guava RateLimiter或Resilience4j：对于单机应用，可以使用Guava的RateLimiter。对于分布式限流，Resilience4j提供了更强大的功能。但Redis方案在分布式环境下更通用。

5.2.2 增强验证码（CAPTCHA）机制验证码能有效阻止机器自动化攻击。但需要注意：

不要始终开启：可以在同一IP或用户连续失败2-3次后，再要求输入验证码。这既不影响正常用户，又能给攻击者制造障碍。
选择安全的验证码：避免使用简单的数字加减、扭曲文字等容易被OCR识别的类型。推荐使用行为验证码，如滑块拼图、点选文字等，用户体验和安全性更好。可以考虑集成第三方服务，如极验、腾讯云验证码等。
后端校验：验证码必须在服务端校验，且一次有效（使用后立即作废）。将验证码文本存储在Session或Redis中，并设置较短的过期时间（如2分钟）。

5.2.3 密码失败延迟与账户锁定

失败延迟：当登录失败时，不立即返回结果，而是让线程睡眠一个随机时间（如1-3秒）。这能显著降低暴力破解的速度。但要注意不要影响系统整体性能，可以仅对连续失败的请求实施。
```
if (loginFailed) { try { Thread.sleep(1000 + new Random().nextInt(2000)); // 延迟1-3秒 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }
```
账户锁定：当某个账号的失败次数达到阈值（如5次）后，临时锁定该账号一段时间（如15分钟）。在数据库中为用户表增加failed_attempts（失败次数）和lock_until（锁定直到）字段。登录失败时递增次数，成功时清零。检查时，如果账号已锁定且当前时间在lock_until之前，则直接拒绝登录。

5.2.4 网络层与基础设施防护

Web应用防火墙（WAF）：在应用前端部署WAF，可以识别并拦截常见的暴力破解攻击模式。
负载均衡器/API网关限流：在Nginx、Spring Cloud Gateway等层面配置全局的速率限制规则，作为第一道防线。
IP黑名单：对于持续进行恶意攻击的IP地址，可以动态加入黑名单，在一段时间内拒绝其所有访问。这需要结合日志分析和自动化脚本。

防御暴力破解没有银弹，关键在于增加攻击者的成本和不确定性。通过应用层限流增加时间成本，通过验证码增加人力成本，通过失败延迟和账户锁定降低尝试频率，再结合基础设施的防护，形成一个纵深防御体系，让自动化攻击变得无利可图。

6. 漏洞五：业务逻辑漏洞与信息泄露——防得住技术攻击，更要防得住“脑洞”

这是最容易被忽视，也往往最致命的一类漏洞。它不涉及复杂的技术突破，而是利用应用程序业务逻辑上的缺陷或设计疏忽。在登录注册场景中，常见的有：用户枚举、短信/邮箱轰炸、越权访问等。

6.1 用户枚举漏洞

在登录或注册时，系统返回的错误信息过于详细，导致攻击者可以判断某个用户名或邮箱是否已在系统中注册。

错误示例：
- 登录时，提示“用户名不存在”和“密码错误”是两种不同的信息。
- 注册时，提示“该邮箱已被注册”。
攻击利用：攻击者可以利用这个漏洞，批量测试常用用户名或邮箱，从而绘制出系统的用户清单，为后续的撞库或精准钓鱼攻击提供目标。

修复方案：统一化错误信息无论登录失败的原因是什么，都返回统一的、模糊的错误信息。例如：“用户名或密码错误”。在注册时，即使邮箱已存在，也提示“注册成功”（但实际上不执行插入操作），然后发送一封“您的邮箱已被注册，如非本人操作请忽略”的邮件到该邮箱。这样既避免了信息泄露，又给了合法用户提示。

public ResponseEntity<?> login(@RequestBody LoginDTO dto) { // 伪代码 User user = userService.findByUsername(dto.getUsername()); boolean success = (user != null && passwordEncoder.matches(dto.getPassword(), user.getPassword())); if (success) { // ... 生成token等 ... return ResponseEntity.ok(“登录成功”); } else { // 统一错误信息 return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body(“用户名或密码错误”); // 同时，可以在后台记录详细的失败日志（IP, 用户名， 失败原因）用于安全分析 log.warn(“登录失败 - IP: {}, 用户名: {}, 原因: {}”, ip, dto.getUsername(), user==null?“用户不存在”:“密码错误”); } }

6.2 短信/邮箱轰炸漏洞

在注册或找回密码时，系统无限制地发送短信或邮件验证码。攻击者可以编写脚本，频繁调用发送接口，导致目标用户的手机或邮箱被海量垃圾信息淹没，造成骚扰和资源浪费。

修复方案：多维度频率限制与验证

发送频率限制：对同一个手机号/邮箱，在单位时间内（如1分钟）只能发送一次验证码。在Redis中记录send:code:13800138000，并设置60秒过期。
每日/每小时总量限制：限制单个手机号/邮箱每天最多接收10条验证码短信。记录day:count:13800138000并累加，每日零点清零。
IP限制：限制单个IP地址在单位时间内的总发送次数，防止攻击者更换手机号进行轰炸。
前置图形验证码：在触发发送短信/邮件按钮前，必须先通过一个图形验证码的校验。这能有效阻止自动化脚本。
业务流程绑定：验证码必须与本次会话或业务请求绑定。例如，在发送验证码时，生成一个临时令牌（Token）与手机号一起存入缓存。用户提交验证码时，必须同时提交这个Token，服务端校验Token与手机号的对应关系。这可以防止攻击者获取到验证码后用于其他手机号。

6.3 越权访问漏洞

用户登录后，能够访问或操作本不属于自己权限范围内的数据。例如，通过修改URL中的用户ID参数（如/api/user/123/order），就能看到用户ID为123的订单信息。

修复方案：强制访问控制与资源归属校验这是业务逻辑安全的基石。永远不要相信客户端传来的任何关于权限或资源归属的信息。

在Controller层进行校验：在每个需要资源ID的接口处理开始时，从当前登录用户的会话或Token中取出用户ID，与请求参数中的资源ID进行比对。

@GetMapping(“/orders/{orderId}”) public ResponseEntity<Order> getOrder(@PathVariable Long orderId, @AuthenticationPrincipal UserDetails userDetails) { Order order = orderService.findById(orderId); if (order == null) { return ResponseEntity.notFound().build(); } // 关键校验：当前登录用户是否是订单的所有者？ if (!order.getUserId().equals(userDetails.getId())) { // 即使找到了订单，但不是他的，也返回404，避免信息泄露 return ResponseEntity.notFound().build(); } return ResponseEntity.ok(order); }

使用Spring Security方法级安全：在Service层的方法上使用@PreAuthorize或@PostAuthorize注解，借助SpEL表达式进行更灵活的权限控制。

@Service public class OrderService { @PreAuthorize(“#order.userId == authentication.principal.id”) public Order updateOrder(Order order) { // 只有订单的所有者才能执行更新 return orderRepository.save(order); } @PostAuthorize(“returnObject.userId == authentication.principal.id”) public Order findOrderById(Long id) { return orderRepository.findById(id).orElse(null); } }

这需要启用全局方法安全注解：@EnableGlobalMethodSecurity(prePostEnabled = true)。

业务逻辑漏洞的修复，考验的是开发者的安全意识和对业务场景的深入理解。核心原则就是“最小权限原则”和“不信任原则”。系统设计的每一步，都要假设用户是恶意的，对所有输入和操作路径进行严格的校验和权限控制，将安全内化到每一个业务逻辑当中。

7. 总结与持续安全实践

安全不是一个功能，而是一个贯穿整个软件开发生命周期（SDLC）的过程。上面这五个漏洞，只是SpringBoot+MyBatis登录注册开发中比较典型的一部分。在实际项目中，还需要关注其他方面，比如：

依赖安全：定期使用OWASP Dependency-Check或GitHub Dependabot扫描项目依赖，更新存在已知漏洞的第三方库。
敏感信息管理：数据库密码、API密钥等绝不能硬编码在代码中。必须使用环境变量、配置中心或专业的密钥管理服务（如HashiCorp Vault）。
日志与监控：记录详细的安全相关日志（登录成功/失败、敏感操作），并设置告警。例如，同一个账号在短时间内从多个国家IP登录，应立即触发告警。
定期安全评估：在项目上线前和定期运行中，进行渗透测试和安全代码审计，主动发现潜在问题。

从我个人的经验来看，培养团队的安全意识比引入任何单一工具都重要。在代码评审中加入安全 checklist，在开发流程中嵌入安全环节（如SAST静态扫描），定期进行安全培训，让“安全第一”成为每个开发者的本能反应。修复漏洞的代价，远高于在设计和编码阶段就避免它。希望这篇指南能帮你和你的团队，扎扎实实地筑牢Web应用的第一道安全大门。