银行高安全要求场景下浏览器端如何安全存储服务器返回的AES密钥

针对银行级安全要求的前端密钥存储场景，以下是经过行业实践验证的可行方案：

方案1：加密存储会话密钥到sessionStorage #

• 核心逻辑：不直接存储明文aesKey和iv，而是用用户身份相关的动态派生密钥对这两个值加密后再存到sessionStorage
• 实现步骤：
  1. 每次用户登录完成后，取用户登录态中的动态一次性因子（比如服务端返回的仅单次有效的会话salt、用户输入的密码哈希片段、设备指纹生成的动态值）作为派生根密钥
  2. 用PBKDF2或者HKDF算法对根密钥做密钥派生，得到专门用于加密aesKey/iv的二级密钥
  3. 用二级密钥加密你从服务端拿到的aesKey和iv，把密文存在sessionStorage里
  4. 页面刷新时，重新从内存/会话cookie里拿到派生根密钥，重新派生二级密钥解密sessionStorage里的密文，拿到明文密钥后只存在内存闭包里使用
• 安全优势：即使sessionStorage被XSS读取，拿到的也是加密后的密文，没有派生根密钥无法解密，符合银行级安全审计要求
• 注意点：派生根密钥不要存在任何本地存储里，只放在内存闭包中，XSS要读取内存变量的难度远高于读本地存储

方案2：Service Worker 内存持久化存储 #

• 核心逻辑：利用Service Worker的生命周期长于普通页面上下文的特性，把密钥存在Service Worker的内存里
• 实现步骤：
  1. 首次从服务端拿到aesKey和iv后，通过postMessage传给已经注册的Service Worker，存在Worker的全局变量里
  2. 后续页面加解密请求都发送给Service Worker，由Worker完成加解密后再返回结果，页面本身不接触明文密钥
  3. 页面刷新时，直接向Service Worker请求密钥即可，不需要重新走密钥获取流程
• 安全优势：Service Worker上下文和普通页面上下文隔离，普通页面的XSS无法直接读取Worker内存里的变量，安全等级更高，同时只要用户不手动关闭整个浏览器，密钥就不会丢失
• 注意点：要做Service Worker被回收后的降级处理，一旦Worker被系统回收，就触发重新走密钥获取流程，对业务无感知

方案3：Web Crypto API 非导出密钥配置 #

• 核心逻辑：用浏览器原生Web Crypto API生成/导入密钥时，设置extractable: false属性，密钥无法被导出明文，只能用于加解密操作
• 实现步骤：
  1. 拿到服务端返回的aesKey明文后，调用crypto.subtle.importKey方法导入密钥，配置参数里extractable设为false，指定密钥仅可用于encrypt和decrypt操作
  2. 导入后的密钥对象是CryptoKey实例，即使被XSS拿到，也无法导出明文值，只能用来做加解密
  3. 可以把这个不可导出的CryptoKey对象存在内存里，也可以加密后存在sessionStorage，即使被导出也是加密后的内容
• 安全优势：原生浏览器API支持，不存在前端代码逻辑漏洞导致密钥明文泄露的风险，符合金融级安全规范

安全兜底补充规则 #

• 所有密钥的有效期设置不超过24小时，到期自动触发重新走密钥生成流程，即使密钥泄露影响范围也可控
• 所有加解密操作都在隔离的JS沙箱或者Web Worker里执行，不要和业务代码混在同一个上下文
• 严格做XSS防护，所有用户输入输出都做转义，启用CSP策略，从根源降低XSS风险

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