Ghost Bits 隐式字符穿透

解决什么问题

当 Java 后端部署在 WAF 或 IDS 之后，攻击者面临的最直接问题是：精心构造的注入载荷在到达应用逻辑前就被规则拦截。这导致在渗透测试或红队评估中，常见的 SQL 注入（SQLi）、反序列化 RCE、路径遍历等载荷往往因为包含明显的 ASCII 特征字符而被阻断。

问题的根源在于 WAF 与后端的解析不一致性。WAF 通常基于字节流进行特征匹配，而 Java 底层的字符处理往往涉及 UTF-16 编码。这就引出了一个经典的安全盲区：如果攻击载荷中混入了非 ASCII 字符，WAF 可能因为无法识别或认为无害而放行，但后端在处理时可能会将其“折叠”回有效的 ASCII 字符，从而还原出完整的攻击指令。

技能如何工作

Ghost Bits 攻击的核心在于利用 Java 语言中 char（16位）到 byte（8位）的强制类型转换逻辑。在 Java 中，将 char 转换为 byte 是一个窄化（Narrowing）转换过程。根据 Java 规范，如果 char 的值超出了 byte 的范围（-128 到 127），高位（High 8 Bits）会被静默截断（Truncate），只保留低 8 位。

该技能的工作流程如下：

• 载荷构造：将原本有效的 ASCII 攻击字节（例如 <、>、'）与一个空字节（\u0000）或其他高位字符组合。例如，Unicode 字符 ¡（U+00A1）在窄化转换时会丢失高 8 位（0xA1），仅保留低 8 位（0x00）……

等等，这个例子不对。应该是：字符 À（U+00C0）在窄化转换时，0xC0 会被视为无符号数，然后截断。更准确的例子是：利用 Unicode 字符 U+003C（<）和 U+0100（Ā），后者的低 8 位是 0x00。实际上，通常是将 ASCII 字符放入 16 位字符的高位，让低 8 位刚好是攻击字符。

让我们修正工作流描述：

• 载荷构造：攻击者利用 Unicode 字符（如 U+0000 到 U+00FF 之间的字符），这些字符在 UTF-16 中包含高 8 位和低 8 位。例如，字符 Ā（U+0100）的低 8 位是 0x00，而 ½（U+00BD）的低 8 位是 0xBD。
• WAF 绕过：当 WAF 扫描到这些 Unicode 字符时，如果规则集只匹配原始 ASCII 字节（如 \x3C），且未正确解码高 8 位后的低 8 位特征，载荷将被视为“无害”而放行。
• 后端还原：Java 后端在读取请求参数或头部时，如果使用了 getBytes() 或其他窄化转换逻辑，会导致高 8 位丢失，后端实际上接收到的是载荷的低 8 字节。通过精心选择 Unicode 字符，攻击者可以确保后端还原出的字节流恰好是有效的 SQLi、路径遍历或反序列化载荷。

适用边界与注意点

• 仅限 Java 后端：此攻击利用的是 Java 特有的类型转换语义。如果后端是 Go、Python 或 Node.js，且未经过特定处理，此方法通常无效。
• 窄化转换前提：目标代码必须执行了从 16 位 char 到 8 位 byte 的强制转换。如果代码始终在 16 位环境下处理字符串（如 String 类型），或者使用了大字节数组，攻击可能无法生效。
• WAF 规则的盲区：虽然此方法绕过了许多基于 ASCII 特征的规则，但现代 WAF 如果配置了针对 Unicode 编码的严格解码规则，仍可能拦截此类载荷。
• 实验性验证：该技能基于 Black Hat Asia 2026 的研究成果，属于前沿的绕过技术。建议在授权的测试环境中验证其对特定 WAF（如 ModSecurity、云厂商 WAF）的有效性。