JWT安全防护实战：从漏洞原理到Spring Security防御策略

1. 项目概述为什么JWT安全防护是每个开发者的必修课在前后端分离和微服务架构成为主流的今天JSON Web TokenJWT几乎成了身份认证和授权的事实标准。它轻量、自包含、易于跨域传输开发者们乐于用它来替代传统的Session-Cookie模式。然而我见过太多项目仅仅是把JWT当作一个“时髦”的令牌来用对其中潜藏的安全风险视而不见直到线上被黑、数据泄露才追悔莫及。这就像给自家大门装了一把结构复杂但钥匙就挂在门把手上的锁。JWT的安全远不止是生成一个Token然后验证签名那么简单。它涉及算法选择、密钥管理、令牌生命周期、声明校验等多个层面任何一个环节的疏忽都可能成为攻击者的突破口。网络上关于“JWT身份认证绕过漏洞”的讨论和CTF中“JWT弱密码”的挑战层出不穷这恰恰说明了问题的普遍性和严重性。本文的目的就是带你从攻击者的视角出发彻底拆解JWT的漏洞原理然后以防御者的身份构建一套从开发到部署的完整防护策略。无论你是正在使用Spring Security JWT构建认证系统还是用SpringBoot处理Token认证甚至是处理文件上传、Nacos配置中心时遇到的间接安全问题这里的思路都至关重要。2. JWT核心机制与安全模型深度解析要打好防御战首先得彻底理解你手中的武器和它的弱点。JWT的安全根植于其设计机制。2.1 JWT结构三要素头、载荷、签名的安全内涵一个JWT通常由三部分组成以点号分隔Header.Payload.Signature。每一部分都承载着特定的安全意义。Header头部通常包含令牌类型typ固定为JWT和签名算法alg如HS256或RS256。这个部分是用Base64Url编码的任何人都可以解码查看。这里的安全关键在于alg声明。攻击者能否篡改其他部分并伪造签名很大程度上取决于服务器如何对待这个alg值。如果服务器盲目信任客户端Token头中的alg就会引发最经典的“算法操控”攻击。Payload载荷包含所谓的“声明”Claims即我们要传递的信息。声明分为三种注册声明预定义的一组声明如iss签发者、exp过期时间、sub主题等。这些是安全策略的基石。公共声明可以自定义但为避免冲突应定义在IANA JSON Web Token Registry或使用防冲突命名空间。私有声明双方约定好的自定义声明用于传递业务信息。安全的核心在于Payload同样只是Base64Url编码完全透明可读可改。其完整性完全依赖于签名。开发者常犯的错误是从Payload中解码出用户ID后就直接使用而不在服务端进行二次校验如查询数据库确认用户状态这为“令牌重用”或“信息篡改”留下了隐患。Signature签名这是JWT安全的灵魂。签名的生成方式取决于头部声明的算法。例如对于HMAC SHA256 (HS256)签名是这样计算的HMACSHA256(base64UrlEncode(header) “.” base64UrlEncode(payload), secret)。签名的作用是验证消息在传递过程中未被篡改并且对于HMAC确认发送方拥有密钥。注意这里有一个关键的安全认知偏差。很多开发者认为JWT是“加密”的。错标准的JWTJWS是签名确保完整性而非加密JWE才是加密的。Header和Payload是明文Base64编码后任何拿到Token的人都能看到其内容。敏感信息如密码、手机号绝对不应该放在Payload中。2.2 签名算法选型HMAC vs RSA/ECDSA 的安全权衡算法选择是安全架构的第一道防线。对称加密算法如HS256/HS384/HS512使用同一个密钥进行签名和验证。优点是计算速度快实现简单。但致命缺点是密钥分发问题。在微服务场景下所有需要验证Token的服务都必须安全地持有同一个密钥。一旦其中一个服务密钥泄露整个系统的安全就崩塌了。这类似于一把钥匙开所有门的场景风险集中。非对称加密算法如RS256/RS384/RS512, ES256/ES384/ES512使用公私钥对。私钥用于签发Token严格保密通常只由认证服务器持有公钥用于验证Token可以安全地分发给所有资源服务器。这样即使公钥被公开也无法伪造Token。这提供了更好的密钥隔离性和更安全的分布式验证模型。实操心得对于新项目我强烈建议直接使用RS256或ES256。虽然比HS256稍慢但带来的安全收益是巨大的。尤其是在微服务架构中你可以将公钥配置在API网关或各个服务中而私钥在认证服务里严加保管。如果历史项目使用了HS256迁移到RS256需要协调Token签发和验证的所有服务虽然麻烦但应作为一个高优先级的安全重构项。2.3 关键注册声明的安全意义JWT的Payload中的一些标准声明是构建自动安全策略的关键exp(Expiration Time)过期时间。必须设置。这是防止Token被盗后无限期使用的首要措施。验证时服务器必须检查当前时间是否在exp之前。nbf(Not Before)生效时间。在此时间之前Token无效。iat(Issued At)签发时间。可用于计算Token年龄结合短期有效期策略可以辅助发现异常。iss(Issuer)签发者。验证Token时应检查是否来自受信任的签发方如你的认证服务器地址。这可以防止来自其他系统的Token被误接受。aud(Audience)受众。指定Token的目标接收方服务名。资源服务器应验证自己是否在aud列表中。这为微服务间的精细授权提供了基础。很多漏洞的产生正是因为服务器端没有严格校验这些声明。例如如果服务器不校验exp那么一个过期的Token将永远有效。3. JWT常见攻击手法与漏洞原理深度剖析了解了机制我们来看看攻击者是如何利用这些机制中的弱点或实现上的疏忽来发起攻击的。这部分内容与“CTF JWT”挑战中的技巧高度相关。3.1 算法操控攻击从“none”算法到密钥混淆这是最经典且危害极大的攻击方式。攻击原理JWT头部中的alg参数本应指示验证签名所需的算法。如果服务器端的验证库存在逻辑缺陷比如1允许alg为none2或者更常见地接收客户端提供的alg并用它来决定验证逻辑那么攻击者就可以实施攻击。none算法攻击攻击者将头部改为{“alg”: “none”, “typ”: “JWT”}并移除签名部分即Token以.结尾。如果服务器配置为接受none算法它会认为这是一个有效的、无需验证签名的Token。现代库默认已禁止此算法但历史代码或错误配置仍可能导致风险。密钥混淆攻击这是更隐蔽的一种。假设系统使用RS256非对称。攻击者篡改头部为{“alg”: “HS256”, “typ”: “JWT”}然后使用认证服务器的公钥本是公开的作为HMAC的密钥来伪造签名。如果服务器验证逻辑是“读取alg-如果是HS256-用配置的密钥这里错误地配置成了公钥去验证HMAC签名”那么攻击者用公钥签名的Token就会被服务器用自己的公钥验证通过因为对于服务器来说它用公钥作为HMAC密钥去计算签名结果正好匹配。漏洞根源服务器验证签名时其用于验证的密钥或算法没有与Token的签发来源强绑定而是依赖于客户端可控的alg字段。3.2 弱密钥破解与暴力枚举当使用HMACHS256等对称算法时密钥的强度至关重要。攻击原理如果密钥设置得过于简单如secret、password、123456等或者密钥是常见的单词、短字符串攻击者可以通过离线暴力破解或字典攻击来获取密钥。一旦密钥泄露攻击者就可以签发任意Token。CTFHub中的“JWT弱密码”挑战就是模拟这种场景。攻击者通常有一个常用的弱密钥字典对截获的Token尝试用这些密钥验证签名如果验证通过则说明密钥被猜中。实操心得绝对不要使用任何形式的弱密钥。HMAC密钥应该是高熵值的随机字符串长度至少等于哈希函数的输出长度如HS256至少32字节。推荐使用安全的随机数生成器生成。对于生产环境密钥应来自安全的配置中心或密钥管理服务而非硬编码在代码中。3.3 未验证声明导致的逻辑绕过这是业务逻辑层面的漏洞而非密码学漏洞。攻击原理服务器解码JWT Payload后直接相信了其中的信息而没有在服务端进行状态复核。常见场景包括直接信任sub或user_id从Token中取出用户ID后直接认为该用户是合法用户不再查询数据库校验用户是否存在、是否被禁用。忽略exp校验服务器代码没有检查Token的过期时间。签名验证后即放行虽然验证了签名但未校验iss、aud等声明导致其他系统签发的、或签发给其他服务的Token在本服务中被接受。这种漏洞的危害在于即使签名机制完好无损攻击者也可以利用一个合法签发但已过期的Token或者通过其他途径获取到一个低权限用户的Token然后通过篡改Payload虽然会导致签名无效但如果服务器不校验——等等这里有个关键如果服务器验证签名那么篡改Payload会导致签名验证失败。所以“未验证声明”攻击通常发生在签名验证通过之后业务逻辑处理Payload的阶段。例如服务器验证签名通过后从Payload拿到user_id: 1001普通用户但业务代码错误地根据另一个字段is_admin: false攻击者无法篡改来赋权而权限检查逻辑有bug可能被绕过。更典型的案例是某些框架或自定义验证逻辑可能存在“条件竞争”或“逻辑缺陷”使得在特定情况下如某些声明缺失时权限校验被跳过。这要求我们对业务代码进行严格的安全审计。3.4 信息泄露与KID参数滥用JWT的头部可以包含一个kidKey ID参数用于在服务器配置了多个密钥时指示应该用哪个密钥来验证签名。这本身是一个好设计。攻击原理信息泄露由于Header和Payload是Base64编码的明文如果开发者在Payload中存放了邮箱、手机号、用户ID等敏感信息任何能接触到Token的地方浏览器本地存储、网络日志、客户端调试工具都会导致信息泄露。这与“SSL/TLS协议信息泄露漏洞”强调的加密传输无关是应用层设计缺陷。KID注入与路径遍历如果kid参数是用户可控的或者服务器根据kid从不可信的位置如文件系统、URL加载密钥文件就可能产生漏洞。例如攻击者设置”kid”: “../../../../etc/passwd”如果服务器代码不安全地拼接路径可能会将系统文件内容作为密钥来验证签名这可能导致签名验证逻辑被绕过例如如果文件内容恰好符合某种格式或直接造成敏感文件读取。JKU/JWK参数滥用jkuJWK Set URL和jwkJSON Web Key头部参数允许Token自带公钥信息。如果服务器未严格限制这些参数指向的URL或内容攻击者可以指向自己控制的服务器提供伪造的公钥从而让用自己的私钥签名的Token被验证通过。3.5 与其它漏洞的联动以文件上传和未授权访问为例JWT安全问题很少孤立存在常与其他漏洞形成“组合拳”。文件上传漏洞如果系统存在文件上传漏洞攻击者可能上传一个包含恶意公钥的文件如malicious.pem。然后结合JWT的jku或kid路径遍历漏洞让服务器从这个上传位置加载“公钥”从而验证攻击者私钥签名的Token。未授权访问漏洞像“Nacos namespaces未授权访问漏洞”这类问题攻击者可能直接访问到存储JWT签名密钥的配置项。如果密钥尤其是HMAC密钥以明文形式存储在配置中心且该配置中心存在未授权访问那么整个JWT体系的门户就洞开了。这提醒我们密钥管理必须作为最高级别的安全事务来处理。4. 构建纵深防御策略从开发到部署的实战指南知其然更要知其所以然。了解了攻击方式我们就可以有针对性地筑起防线。防御不是单点而是一个立体的体系。4.1 安全的令牌生成与签发实践签发端是安全的起点。选用强算法首选RS256或ES256。使用非对称算法将签发密钥和验证密钥分离。使用强密钥对于RSA密钥长度至少2048位推荐3072位或以上。对于HMAC如确需使用密钥必须是密码学安全的随机字符串长度足够如32字节以上。可以通过openssl rand -base64 32命令生成。密钥必须存储在安全的地方如专用的密钥管理服务KMS、HashiCorp Vault或至少是受严格访问控制的配置服务器中。严禁硬编码在源代码或客户端。精心设计Payload仅包含必要信息。绝对不要放入密码、信用卡号等敏感信息。必须设置合理的exp短期有效如15-30分钟。对于刷新令牌可以设置较长的有效期但需单独管理。设置iss签发者标识和aud受众即服务名。可以加入自定义声明如jtiJWT ID用于实现令牌吊销清单黑名单。控制令牌生命周期采用“访问令牌刷新令牌”模式。访问令牌短期有效刷新令牌长期有效但仅用于获取新的访问令牌且可被吊销。这限制了访问令牌泄露后的影响窗口。4.2 稳健的令牌验证逻辑实现验证端是防守的主阵地。这里以伪代码展示关键校验步骤实际应使用成熟库如java-jwt,jsonwebtoken,pyjwt等但需理解其原理并正确配置。// 伪代码示例一个健壮的JWT验证流程 public boolean validateJwt(String token, String expectedIssuer, String expectedAudience) { try { // 1. 解码并验证基本结构三段点号分隔 if (!isValidStructure(token)) { return false; } // 2. 解码Header但不信任其中的alg DecodedJWTHeader header decodeHeader(token); // 3. 【关键防御】固定算法禁止从Token头动态选择 // 明确指定你的系统只接受一种或几种算法而不是读取header.alg Algorithm algorithm Algorithm.RSA256(publicKey, null); // 固定使用RSA256和你的公钥 // 或者如果你支持多种算法建立一个安全的映射而不是直接使用header.alg // Algorithm algorithm getAlgorithmSafely(header.getKeyId()); // 根据kid从可信源获取算法和密钥 // 4. 使用固定的算法和密钥进行签名验证 JWTVerifier verifier JWT.require(algorithm) .withIssuer(expectedIssuer) // 强制校验签发者 .withAudience(expectedAudience) // 强制校验受众 .build(); DecodedJWT decodedJWT verifier.verify(token); // 此方法内部会验证签名和exp/nbf等时间声明 // 5. 额外的业务逻辑校验可选但推荐 String userId decodedJWT.getSubject(); if (!isUserActive(userId)) { // 查询数据库确认用户状态 return false; } if (isTokenInBlacklist(decodedJWT.getId())) { // 检查jti是否在黑名单 return false; } return true; } catch (JWTVerificationException | InvalidClaimException e) { // 记录日志用于审计和异常监控 log.warn(“JWT validation failed: ”, e.getMessage()); return false; } }关键防御点解析算法固定/安全映射这是防御算法操控攻击的核心。不要使用类似Algorithm.HMAC256(secret)这种从配置读取secret且算法可能被alg头影响的方式。对于非对称算法直接使用公钥和固定算法创建验证器。强制校验标准声明利用验证器构建器如.withIssuer()强制校验issaudexp等。成熟的库会在verify()方法中自动完成这些校验。校验kid如果使用如果使用kid应预先配置一个可信的kid到公钥的映射表JWKS验证时只从该映射表中查找公钥绝不根据kid动态从不可信源加载。禁用危险参数除非有明确且安全的需求否则应在服务器端禁用对jku、jwk等参数的支持。4.3 密钥管理与安全存储进阶方案密钥是皇冠上的明珠。密钥轮转定期更换密钥。对于RSA可以生成新的密钥对将新旧公钥同时部署到验证端一段时间重叠期逐步淘汰旧密钥。对于HMAC轮转需要更谨慎因为所有服务需同时切换。使用JWKS端点对于非对称加密认证服务器可以提供一个JWKSJSON Web Key Set端点动态发布其公钥集。资源服务器定期如有缓存或每次验证时从该可信端点获取公钥。这简化了公钥分发并便于密钥轮转。确保该端点本身安全如通过HTTPS、内网访问等。环境隔离开发、测试、生产环境使用完全不同的密钥。避免测试密钥泄露影响生产系统。4.4 令牌传输与存储的客户端安全Token在客户端的安全同样重要。传输安全始终使用HTTPS。防止Token在传输过程中被窃听或中间人攻击。这与修复“SSL/TLS协议信息泄露漏洞”的目标一致——确保传输层安全。客户端存储避免 localStorage虽然方便但易受XSS攻击。如果JavaScript可以访问那么注入的恶意脚本也能偷走Token。优先使用 HttpOnly Cookie将Token放在HttpOnly、Secure、SameSiteStrict的Cookie中。这可以防止JavaScript访问从而免疫XSS窃取。但需注意防范CSRF攻击此时需要配套CSRF Token。移动端/桌面端使用安全的存储机制如iOS的Keychain、Android的Keystore、或安全的本地加密存储。设置合理的Cookie属性Secure: 仅通过HTTPS传输。HttpOnly: 禁止JavaScript访问。SameSiteStrict(或Lax): 提供良好的CSRF防护。Path和Domain: 精确设置范围。4.5 会话管理与吊销机制JWT的无状态性是其优点也是缺点。我们无法像Session一样直接使其失效。短期令牌访问令牌设置短有效期如15分钟大幅减少泄露后的风险窗口。令牌吊销清单黑名单对于需要主动失效的场景如用户登出、密码修改可以将令牌的jti加入一个黑名单如存入Redis并设置TTL略大于令牌原有效期。验证Token时除了校验签名和时间还需查询黑名单。这引入了状态但平衡了安全与需求。使用刷新令牌用户使用长期有效的刷新令牌获取短期访问令牌。刷新令牌可以单独吊销从数据库中删除或加入黑名单从而使用户的所有会话失效。并发会话管理如果需要限制同一用户的并发会话数可以在用户记录中保存最新令牌的jti或签发时间验证时进行检查。5. 实战场景整合Spring Security与JWT的安全架构结合热搜词中的“Spring Security JWT”和“SpringBoot 3.5 JWT的Token认证”我们来看一个实战架构。这里假设使用RS256算法。5.1 架构概览与组件职责认证服务 (Auth Server)负责用户登录验证。使用私钥签发JWT访问令牌和刷新令牌。提供JWKS端点 (/oauth/jwks)公布公钥。处理刷新令牌换取新访问令牌的请求。维护刷新令牌与用户的映射关系支持吊销。资源服务 (Resource Servers)提供受保护的API。从认证服务的JWKS端点获取或预配置公钥。在API网关或每个服务的过滤器中验证JWT校验签名、iss、aud、exp等。实现黑名单检查可选查询Redis。客户端 (Web/ Mobile)登录后获取Token存储在HttpOnly Cookie或安全存储中。访问API时携带Token通常通过Authorization: Bearer token头。在访问令牌过期前使用刷新令牌静默获取新令牌。5.2 核心配置与代码要点Spring Boot 示例认证服务端签发// 使用JJWT库示例 import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; import java.security.KeyPair; import java.security.KeyPairGenerator; import java.util.Date; Service public class TokenProvider { private final KeyPair keyPair; // RSA密钥对从配置或KMS加载 private final long accessTokenValidity; private final long refreshTokenValidity; public String createAccessToken(UserDetails userDetails) { Date now new Date(); Date validity new Date(now.getTime() accessTokenValidity); return Jwts.builder() .setSubject(userDetails.getUsername()) .setIssuer(“your-auth-server”) // 设置iss .setAudience(“your-resource-server”) // 设置aud .setIssuedAt(now) .setExpiration(validity) .setId(UUID.randomUUID().toString()) // 设置jti用于黑名单 .claim(“roles”, userDetails.getAuthorities()) // 自定义声明 .signWith(keyPair.getPrivate(), SignatureAlgorithm.RS256) // 使用私钥签名 .compact(); } // 提供JWKS端点 GetMapping(“/.well-known/jwks.json”) public MapString, Object getJwks() { // 构造包含公钥信息的JWKS RSAPublicKey publicKey (RSAPublicKey) keyPair.getPublic(); MapString, Object jwk new HashMap(); jwk.put(“kty”, “RSA”); jwk.put(“kid”, “your-key-id”); jwk.put(“use”, “sig”); jwk.put(“alg”, “RS256”); jwk.put(“n”, Base64.getUrlEncoder().withoutPadding().encodeToString(publicKey.getModulus().toByteArray())); jwk.put(“e”, Base64.getUrlEncoder().withoutPadding().encodeToString(publicKey.getPublicExponent().toByteArray())); // … 返回包含此JWK的Set } }资源服务端验证 在Spring Security配置中通常使用一个JwtAuthenticationFilter。Component public class JwtAuthenticationFilter extends OncePerRequestFilter { Autowired private JwtDecoder jwtDecoder; // 使用Spring Security OAuth2 Resource Server的JwtDecoder Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) ... { String token resolveToken(request); if (token ! null) { try { // JwtDecoder会自动验证签名、exp等标准声明 Jwt jwt jwtDecoder.decode(token); // 自定义额外校验黑名单、用户状态等 if (!isTokenValid(jwt)) { throw new JwtValidationException(“Token invalidated”); } // 构建Authentication对象并设置到SecurityContext Authentication auth convertJwtToAuthentication(jwt); SecurityContextHolder.getContext().setAuthentication(auth); } catch (JwtException e) { // 验证失败清理上下文返回401 SecurityContextHolder.clearContext(); response.sendError(HttpServletResponse.SC_UNAUTHORIZED, “Invalid JWT”); return; } } chain.doFilter(request, response); } private String resolveToken(HttpServletRequest request) { String bearerToken request.getHeader(“Authorization”); if (StringUtils.hasText(bearerToken) bearerToken.startsWith(“Bearer “)) { return bearerToken.substring(7); } return null; } }配置JwtDecoder (使用JWKS端点)# application.yml spring: security: oauth2: resourceserver: jwt: issuer-uri: https://your-auth-server/.well-known/jwks.json # jwk-set-uri: https://your-auth-server/oauth/jwks # 也可以直接指定JWKS URI这样配置后Spring Security会自动从issuer-uri发现的元数据中获取jwks_uri并缓存公钥用于验证。5.3 整合Redis实现令牌黑名单对于吊销需求可以在资源服务的验证逻辑中加入Redis检查。Service public class TokenBlacklistService { Autowired private RedisTemplateString, String redisTemplate; private static final String BLACKLIST_KEY_PREFIX “jwt:blacklist:”; public void blacklistToken(String jti, long ttlInSeconds) { String key BLACKLIST_KEY_PREFIX jti; redisTemplate.opsForValue().set(key, “revoked”, Duration.ofSeconds(ttlInSeconds)); } public boolean isTokenBlacklisted(String jti) { String key BLACKLIST_KEY_PREFIX jti; return Boolean.TRUE.equals(redisTemplate.hasKey(key)); } }然后在JwtAuthenticationFilter的isTokenValid方法中调用isTokenBlacklisted(jwt.getId())。6. 安全测试、监控与应急响应安全是一个持续的过程而非一劳永逸的配置。6.1 针对JWT的专项安全测试在开发和测试阶段应主动进行安全测试。使用专业工具像Burp Suite的JWT Editor插件就是绝佳的工具。它可以方便地解码、编辑、重签JWT用于测试算法操控、弱密钥、声明绕过等。测试用例设计修改alg为none观察服务器是否拒绝。修改alg从RS256到HS256尝试用公钥作为HMAC密钥重签观察是否被接受密钥混淆攻击。篡改Payload后重签使用弱密钥字典尝试重签测试密钥强度。过期/未生效的Token发送一个过期的Token看服务器是否返回401。错误的iss或aud修改这些声明看校验是否生效。删除签名发送一个只有Header和Payload的Token看是否被拒绝。测试kid路径遍历如果使用kid尝试注入路径如../../config/application.properties。依赖库安全检查定期检查所使用的JWT库如java-jwt,auth0/jwt,pyjwt是否有安全更新。使用OWASP Dependency-Check等工具扫描项目依赖。6.2 日志、监控与告警完善的监控能让你在出事前发现苗头。详细记录认证日志记录所有Token验证的成功和失败事件包括失败原因签名无效、过期、iss不匹配等、来源IP、用户标识如果可能。这有助于发现扫描和攻击行为。监控异常模式短时间内大量401错误可能是在暴力破解或扫描。同一个用户账号从地理位置上不可能的两个地方快速连续登录。大量使用已过期Token的请求可能尝试重放攻击。设置告警对上述异常模式设置阈值告警及时通知安全团队。6.3 应急响应当怀疑JWT泄露时立即吊销相关令牌如果支持黑名单立即将疑似泄露令牌的jti加入黑名单。如果使用刷新令牌模式吊销该用户的刷新令牌。密钥轮转如果怀疑是HMAC密钥泄露或私钥泄露立即启动紧急密钥轮转。所有用户需要重新登录。调查与溯源分析日志确定泄露可能发生的时间、地点和方式客户端恶意软件日志泄露中间人攻击。通知用户如果涉及用户数据风险根据相关法规和公司政策决定是否需要通知受影响的用户。JWT的安全防护是一个系统工程它贯穿于设计、开发、测试、部署和运维的全生命周期。没有银弹唯有对原理的深刻理解、对细节的严谨把控、以及持续的安全投入才能构建起真正可靠的数字身份防线。从今天起审视你的JWT实现别让它成为系统中最脆弱的一环。