面试题：微服务架构下JWT认证的安全隐患与应对策略

Question

尽管JWT在微服务安全认证方面有诸多优势，但也存在一些安全隐患。请深入分析这些潜在的安全风险，例如JWT被盗用、密钥管理等问题，并提出相应的全面应对策略。

Answer 1

JWT安全隐患分析

1. JWT被盗用
   • 风险：由于JWT通常在客户端存储（如浏览器的localStorage或cookie），如果客户端遭受XSS（跨站脚本攻击），攻击者可以获取到JWT，从而以合法用户身份访问系统资源。另外，在网络传输过程中，如果没有采用安全的传输协议（如HTTPS），JWT可能被中间人截取。
   • 示例：攻击者在网页中注入恶意脚本，当用户访问该页面时，脚本读取存储在localStorage中的JWT并发送到攻击者服务器。
2. 密钥管理
   • 风险：JWT的签名验证依赖于密钥，如果密钥泄露，攻击者可以伪造合法的JWT。此外，密钥的生成、存储和更新过程如果处理不当，也会带来安全风险。例如，使用弱密钥或者将密钥硬编码在代码中。
   • 示例：开发人员为了方便，将密钥明文写在配置文件中，并且该配置文件在版本控制系统中未进行加密，导致密钥泄露。
3. 过期时间设置不当
   • 风险：如果JWT的过期时间设置过长，被盗用的JWT在较长时间内都能使用，增加了系统被攻击的窗口；而过期时间设置过短，可能导致用户频繁重新登录，影响用户体验。
   • 示例：为了避免用户频繁登录，将JWT过期时间设置为一年，期间JWT被盗用，攻击者可在一年内持续利用该JWT访问系统。
4. 未验证签名
   • 风险：如果服务器端在接收JWT时未对其签名进行验证，攻击者可以轻易伪造JWT，绕过认证机制访问受保护资源。
   • 示例：开发人员在开发过程中为了快速测试功能，临时禁用了JWT签名验证，上线后忘记恢复，导致系统存在严重安全漏洞。

应对策略

1. 防止JWT被盗用
   • 安全存储：避免在客户端使用localStorage存储JWT，推荐使用HttpOnly cookie，这样可以防止XSS攻击获取JWT。同时，服务端应设置合适的cookie属性，如secure（仅通过HTTPS传输）和same - site（防止跨站请求伪造）。
   • 安全传输：在网络传输过程中，始终使用HTTPS协议，确保数据在传输过程中的保密性和完整性，防止中间人攻击截取JWT。
2. 密钥管理
   • 强密钥生成：使用安全的随机数生成算法生成足够长度和强度的密钥。例如，使用加密安全的伪随机数生成器（CSPRNG）生成256位或更长的密钥。
   • 安全存储：将密钥存储在安全的位置，如硬件安全模块（HSM）或云提供商提供的密钥管理服务（KMS）。避免将密钥硬编码在代码中或存储在普通配置文件中。
   • 定期更新：定期更新密钥，降低密钥泄露带来的风险。在更新密钥时，要确保系统能够平滑过渡，不影响正常用户的使用。例如，可以采用双密钥机制，在一段时间内同时支持新旧密钥进行签名验证，逐步淘汰旧密钥。
3. 合理设置过期时间
   • 动态调整：根据业务场景和安全需求，合理设置JWT的过期时间。对于一些对安全性要求较高的操作，可以设置较短的过期时间，如敏感信息查询、资金交易等；对于一般性的操作，可以设置相对较长的过期时间。同时，可以考虑提供刷新令牌（refresh token）机制，当JWT过期时，用户可以使用刷新令牌获取新的JWT，而无需重新登录，平衡安全与用户体验。
   • 续签机制：对于长时间使用的应用场景，引入续签机制。例如，当用户在应用中持续活跃时，在JWT临近过期时，自动为用户续签新的JWT，延长用户的登录状态。
4. 严格验证签名
   • 服务器端验证：在服务器端接收JWT时，必须严格验证其签名。使用成熟的JWT库，这些库通常提供了方便的签名验证方法。在应用启动时，确保签名验证机制正确配置并生效，在每次处理受保护资源的请求时，都要进行签名验证。
   • 验证频率：除了在请求进入时验证签名，对于一些长时间运行的操作或会话，可以在关键节点再次验证JWT签名，确保在操作过程中JWT未被篡改。