
各大云厂商都有面向 AI 推理请求的文本内容检测业务。对于一个 AI platform 来说AI Guardrail 是不可或缺的功能。最近我想到了一种较为通用的可以绕过文本检测的手段。为了简单起见让我们假定这样的文本检测业务是使用一个规则来查找输入里面有没有给定的文本。世界上没有一个系统是可以接收无限大的输入的。一旦输入达到特定值就会触发异常打开通往新世界的大门。这次的手段也是如此。Azure Content Safety 和阿里云内容检测都是一次请求最多支持 10000 个字符。AI Guardrail 通常部署在代理上。如果这个代理只是把内容提取出来发送给检测系统那么当一个请求里含有超过 10000 个字符时就会触发检测系统报错。假如代理的开发者秉持旁路不影响主业务的准则可能会在收到检测系统报错时直接放行。读者应该会意识到即使这里放行了我们塞入的超过 10000 个字符也难以造成什么危害因为真正不想让 AI 看到的内容可能就淹没在海量垃圾信息里了。但我们可以利用上某种特殊 token连续空白字符。在 GPT 模型的 tokenizer 里连续 128 个空白是一个 token。所以当我们使用这种 token 作为 padding 去触发超过 10000 个字符的报错时只需要一共 80 个 token。对于大模型来说额外 80 个 token 对语义的影响相对较小尤其是这种 token 是一种空白字符。这个并非 GPT 模型特有的缺陷Gemini 模型也会把连续大量空白当作一个 token虽然没有 GPT 那么夸张。事实上由于大模型训练数据里面难免会有许多空格在 BPE 编码下出于优化它们会大概率合并成一个 token。所以这种连续空白的 token 是相当普遍的。在我们的攻击中它会是廉价而好用的障眼法掩护目标内容瞒天过海。需要补充的是攻击成立的前提是代理在检测服务报错或超限时选择直接放行这在实际部署中并非必然若代理对异常请求直接拒绝或截断则威胁降低。但该思路仍揭示了安全链路中常见的静默失败隐患值得重视。如果代理在使用 AI Guardrail 的时候知道提前分割请求避免出现内容过多的情况是不是就能避免被攻击了也不尽然。许多代理在分割时直接采用固定的常数作为单次请求的最大长度。比如开源的 Higress这种常数就是 1800. 即使是不开源的系统也可以借助一次次尝试算出它的最大长度是多少。比如不停地用连续空白 token 来向后推目标内容如果突然不会被拦截了说明刚好落到边界上。所以对于高保的目标应当在分割时保留上一次请求的若干尾部内容append 到下一次请求上这样落到边界上的内容也能够被识别出来。这一尾部保留可以设置成固定最小大小 随机的 offset这样就几乎不可能被人试出来了。由此可见绕过 AI Guardrail 的钥匙有时并不藏在复杂的对抗样本里而就藏在“超过 10000 个字符就报错”这种看似无害的工程约束中。当连续空格成为一种近乎透明的载荷攻击者便可以在检测系统的盲区里从容通行。毕竟在安全的棋盘上任何一个被忽略的角落都可能是对手预订的突破口。http://www.iqiyi.com/v_1otj4b8ok7o.htmlhttp://www.iqiyi.com/v_1tfzfcmjz6c.htmlhttp://www.iqiyi.com/v_syboggp5b0.htmlhttp://www.iqiyi.com/v_15x1cmpwajs.htmlhttp://www.iqiyi.com/v_22e55bzzhb8.htmlhttp://www.iqiyi.com/v_1ifr8sir61k.htmlhttp://www.iqiyi.com/v_1hlw8bv64to.htmlhttp://www.iqiyi.com/v_21cj4ql3ejc.html