AES/CBC/PKCS5Padding填充Oracle攻击及SonarQube加密配置咨询

一、填充Oracle攻击的核心原理 #

填充Oracle是CBC分组加密模式搭配可验证填充机制时的经典高危漏洞，攻击过程不需要获取密钥即可解密任意密文，甚至可以伪造合法密文：

• CBC模式解密时会先校验PKCS5/PKCS7填充的合法性，如果解密端针对填充错误返回差异化响应（比如单独返回填充错误提示、填充错误和密钥错误/签名错误的HTTP状态码、响应内容、响应时间有明显区别），攻击者就可以逐字节篡改密文块。
• 攻击者根据响应判断篡改后的密文是否符合填充规则，平均256次请求就能爆破出1个字节的明文，一个标准16字节的AES密文块仅需数千次请求即可完全解密，攻击门槛极低。
• 你当前使用的AES/CBC/PKCS5PADDING配置，刚好是该攻击的典型受影响组合，这也是SonarQube触发安全告警的核心原因。

二、现有代码的额外安全隐患 #

你的代码是从旧TripleDES逻辑迁移而来，除了填充Oracle风险外还存在多个问题：

• 密钥派生逻辑错误：将16字节原密钥拼接前8字节凑成24字节AES密钥是3DES时代的遗留逻辑，会直接让密钥熵值减半，大幅降低暴力破解成本，完全不符合AES密钥安全要求。
• IV使用不符合规范：CBC模式要求初始化向量IV必须是密码学安全的随机值，且每次加密都必须更换，你使用固定静态vectorInicial的写法会直接废掉CBC模式的防护能力，攻击者通过多组密文即可推导明文规律。
• 冗余逻辑风险：自定义afegir0Multiple8补0逻辑叠加原生PKCS5Padding属于多余操作，既增加对接复杂度，也容易引入解析层漏洞。
• 编码不统一：多处调用getBytes()未指定字符集，不同运行环境默认编码差异会直接导致加解密结果不一致。

三、SonarQube推荐加密方案的实际影响 #

SonarQube针对CBC填充Oracle风险的推荐方案主要分两类，两类方案的影响和适用场景明确：

• 推荐优先级最高的是AES/GCM/NoPadding（AEAD认证加密模式）
  • 正向影响：算法层面自带完整性校验，天然免疫填充Oracle攻击，性能优于CBC搭配HMAC签名的方案，是目前OWASP、NIST官方推荐的对称加密标准配置。
  • 对接影响：需要和外部系统约定参数：使用12字节长度随机IV（GCM标准推荐值）、128位认证标签，IV每次加密随机生成即可，不需要保密，可直接拼接在密文头部传输。
• 兼容场景下推荐的是CBC模式搭配HMAC签名
  • 正向影响：对老系统改造成本低，不需要更换核心加密逻辑。
  • 负面影响：实现极易踩坑——必须遵循“先加密后签名”规则，签名范围必须覆盖IV和密文，收到数据必须先验签再解密，顺序错误依然会存在漏洞；同时所有解密报错必须统一返回“解密失败”，不能区分填充错误、密钥错误、签名错误，否则依然会被填充Oracle攻击，长期维护成本高。
• 注意：不要选用ECB模式，该模式下相同明文块会生成相同密文块，直接泄露数据规律，安全性比固定IV的CBC模式还差。

四、加密配置选型依据 #

选型按照优先级从高到低排列，无特殊兼容要求时直接选最高优先级方案即可：

1. 首选：AES/GCM/NoPadding
   • 适用场景：新开发功能、外部系统支持调整加密配置的场景，是当前对称加密的最优解，可同时满足保密性、完整性要求，无公开高危攻击面。
   • 强制要求：AES密钥必须为16/24/32字节的密码学安全随机值，禁止自定义拼接弱密钥；IV每次通过SecureRandom生成12字节随机值，禁止使用静态固定IV；认证标签长度固定为128位。
2. 次选：AES/CBC/PKCS5Padding + HMAC-SHA256（先加密后签名）
   • 适用场景：外部系统无法支持GCM模式的强兼容场景。
   • 强制要求：IV每次生成16字节随机值，禁止静态固定；AES密钥和HMAC密钥必须为独立生成的随机密钥，禁止复用；收到密文必须先验签，验签通过后再解密；所有解密阶段的错误统一返回相同提示，堵死填充Oracle的探测通道。
3. 绝对禁止使用的配置：
   • AES/ECB开头的所有模式
   • 使用静态固定IV的CBC/GCM模式
   • 自定义填充规则、自定义加密流程的非标准实现
   • 长度不足128位、或通过重复拼接生成的弱密钥

参考实现（AES/GCM最小可用代码） #

import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.security.SecureRandom;
import java.util.Base64;

public class AesGcmUtil {
    private static final int GCM_IV_LEN = 12;
    private static final int GCM_TAG_LEN = 128;
    private static final String CIPHER_ALG = "AES/GCM/NoPadding";

    public static String encrypt(byte[] plainContent, byte[] aesKey) throws Exception {
        byte[] iv = new byte[GCM_IV_LEN];
        new SecureRandom().nextBytes(iv);
        Cipher cipher = Cipher.getInstance(CIPHER_ALG);
        SecretKey secretKey = new SecretKeySpec(aesKey, "AES");
        GCMParameterSpec parameterSpec = new GCMParameterSpec(GCM_TAG_LEN, iv);
        cipher.init(Cipher.ENCRYPT_MODE, secretKey, parameterSpec);
        byte[] encryptData = cipher.doFinal(plainContent);
        // IV不需要保密，直接和密文拼接返回
        byte[] combined = new byte[iv.length + encryptData.length];
        System.arraycopy(iv, 0, combined, 0, iv.length);
        System.arraycopy(encryptData, 0, combined, iv.length, encryptData.length);
        return Base64.getEncoder().encodeToString(combined);
    }

    public static byte[] decrypt(String cipherText, byte[] aesKey) throws Exception {
        byte[] combined = Base64.getDecoder().decode(cipherText);
        byte[] iv = new byte[GCM_IV_LEN];
        byte[] encryptData = new byte[combined.length - GCM_IV_LEN];
        System.arraycopy(combined, 0, iv, 0, iv.length);
        System.arraycopy(combined, iv.length, encryptData, 0, encryptData.length);
        Cipher cipher = Cipher.getInstance(CIPHER_ALG);
        SecretKey secretKey = new SecretKeySpec(aesKey, "AES");
        GCMParameterSpec parameterSpec = new GCMParameterSpec(GCM_TAG_LEN, iv);
        cipher.init(Cipher.DECRYPT_MODE, secretKey, parameterSpec);
        // GCM自动校验完整性，校验失败直接抛出异常，不存在填充Oracle风险
        return cipher.doFinal(encryptData);
    }
}

注意：上述代码中的aesKey必须通过密码学安全随机数生成，禁止硬编码在代码中，禁止使用重复拼接生成的弱密钥。

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