XSS攻击能否替换IndexedDB中存储的CryptoKey为恶意密钥？

结论：一旦存在可替换CryptoKey对象的XSS漏洞，这种机制的安全性完全不可靠

核心原因 #

{extractable:false}的设计目标仅仅是防止密钥原始数据被导出（比如通过exportKey方法获取密钥的二进制或文本形式），避免密钥被窃取后在其他环境复用。但它从一开始就没考虑过当前页面JavaScript执行环境被攻破的情况：

• XSS攻击者拿到页面控制权后，能直接读写IndexedDB，轻易把存储的合法CryptoKey引用替换成自己生成的恶意密钥对象（比如生成一个extractable:true的密钥，或者直接用自己控制的密钥）
• 攻击者还能拦截所有WebCrypto API调用，强制使用恶意密钥执行加解密、签名验签操作，用户完全无法感知到密钥已经被替换

实际风险场景 #

举两个典型例子：

1. 加密数据泄露：用户用合法密钥加密敏感数据后存入IndexedDB，攻击者替换密钥后，后续用户加密的数据会用恶意密钥加密，攻击者拿到密文后可以直接解密获取敏感信息
2. 签名/验签被伪造：用户用合法密钥做签名操作，攻击者替换密钥后，签名会变成攻击者控制的密钥生成的内容；验签环节同理，攻击者可以替换验签密钥，让恶意数据通过验证

本质问题 #

WebCrypto的密钥安全完全依赖于页面的JavaScript执行环境的安全性。只要页面存在XSS漏洞，客户端侧的所有安全机制都会失效——不管密钥是否可提取，攻击者都能操控密钥相关的所有操作。

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