为什么采用AES加密存储敏感数据能缓解SQL注入引发的数据泄露

数据库加密不能缓解SQL注入漏洞本身，仅能降低拖库后的数据泄露危害；攻击者仍可执行任意SQL获取密文，但无密钥无法解密身份证号、手机号等敏感字段。

它不能缓解SQL注入本身，但能大幅降低注入成功后的数据泄露危害。

SQL注入和加密是两个独立层面的问题

SQL注入是输入验证与查询构造缺陷导致的执行逻辑被篡改；AES加密是对静态数据做机密性保护。攻击者即使通过 UNION SELECT 或报错注入把整张表拖出来，拿到的也只是密文——没有密钥，就解不出身份证号、手机号这些原始值。

• 注入漏洞还在，该绕过认证还是能绕过，该删库照样能删库
• 但「拖库即失守」的连锁反应被切断了：密文无法直接用于诈骗、撞库或社工
• 你查 SELECT encrypted_id_card FROM users WHERE id = 123 返回的是乱码，不是真实号码

为什么非得用AES-256-GCM，而不是AES_ENCRYPT()裸调用？

MySQL 的 AES_ENCRYPT() 在 5.7 默认用 ECB 模式，相同明文永远生成相同密文，等于给攻击者发字典。8.0+ 虽支持 GCM，但必须显式传入 iv 和 aad，且应用层要自行校验 auth_tag —— 否则攻击者可篡改密文触发填充预言攻击。

• ECB 模式下，两个用户填同一个手机号，数据库里密文一模一样，直接暴露重复性
• AES_ENCRYPT(data, key) 不带 IV 参数时，MySQL 内部可能复用固定 IV，等同于 ECB
• GCM 模式要求每次加密用新随机 iv，并存下来；解密时必须原样传回，缺一不可

加密后还能按手机号查询吗？

不能直接 WHERE encrypted_phone = ?，因为每次加密结果不同。真要支持查询，得额外设计辅助机制，比如：

• 对手机号算 HMAC-SHA256(phone, salt_from_kms) 存进 phone_hash 字段，建索引；查的时候同样哈希再比对
• 用确定性加密（如 AES-SIV），但会泄露「哪些记录的手机号相同」，隐私有折损
• 完全不想泄露任何模式？目前没成熟方案支持高并发场景下的可搜索加密（Searchable Encryption）

最常被忽略的一点：密钥保管比算法选择更关键。哪怕用了 AES-256-GCM，密钥硬编码在代码里、存在数据库同一实例中、或用环境变量明文暴露，都等于锁了门却把钥匙焊在门把手上。