React与ASP.NET Core中加密存储令牌的XSS攻击安全性疑问

核心结论 #

用符合FIPS标准的AES-256加密令牌并存入非HttpOnly Cookie，无法从根本上抵御XSS攻击带来的令牌泄露风险，加密只能作为辅助防御手段，不能替代HttpOnly Cookie的核心防护作用。

为什么加密不能解决XSS问题 #

• 前端解密令牌必须依赖密钥，而密钥必然要在前端环境中存储（硬编码、动态下发后存在内存/存储中）。XSS攻击者可以通过注入恶意脚本读取到密钥，进而解密出明文令牌。
• 即使攻击者不解密，也可以直接窃取加密后的令牌，将其发送到自己的服务器，再通过模拟前端逻辑解密，或者直接用加密后的令牌冒充用户请求刷新接口（如果后端接受加密后的令牌的话）。
• 非HttpOnly Cookie本身就允许前端JS读取，XSS脚本可以直接获取到Cookie中的加密令牌，整个加密环节对XSS攻击来说几乎没有阻碍。

关于你之前的HttpOnly Cookie问题 #

你遇到的API始终获取旧/过期refresh token的问题，大概率是Cookie配置或更新逻辑有误，建议排查以下几点：

• 确保Cookie设置了正确的SameSite属性（推荐Strict或Lax），避免跨域/跨站点请求时Cookie不被携带。
• 检查Path和Domain配置，确保API所在路径能正确读取到Cookie。
• 刷新token时，后端必须返回新的refresh token并设置新的Cookie（覆盖旧的），同时在后端存储（如Redis）中标记旧refresh token为失效。
• 确保Cookie开启Secure属性（仅HTTPS环境下生效），避免明文传输导致的Cookie篡改或丢失。

当前方案的改进建议 #

如果暂时无法修复HttpOnly Cookie的问题，可以通过以下方式降低风险：

• 严格防控XSS：开启内容安全策略（CSP），禁止内联脚本和未授权的第三方脚本源；对所有用户输入做严格的转义和过滤，避免注入攻击。
• 缩短令牌有效期：将refresh token的有效期从7天缩短至更短（如1天），降低令牌泄露后的攻击窗口。
• 实现令牌撤销机制：后端维护有效的refresh token列表，一旦检测到异常请求（如异地登录），立即撤销对应令牌。
• 密钥动态下发：避免将加密密钥硬编码在前端代码中，在用户登录后通过后端接口动态下发密钥并存在内存中（而非持久化存储），降低密钥被窃取的概率。

内容的提问来源于stack exchange，提问作者asallan3