Zend环境下CakePHP查询构造器where()调用是否存在SQL注入风险

核心结论 #

该写法存在明确的安全隐患，既可能触发SQL注入，也会造成越权查询类问题——并非只要使用了CakePHP ORM的find方法就可以完全规避安全风险

风险产生的根源 #

• 不少开发者存在认知误区：认为只要调用了ORM查询构建器，无论参数如何拼接都会自动完成安全转义。实际上CakePHP ORM的自动参数转义存在明确的生效边界：只有当动态值作为独立的where条件值传入时，才会走参数绑定、自动转义的流程。你当前的写法是把动态的$id变量直接拼接进REGEXP的匹配规则字符串中，整个拼接后的字符串会被作为整体值传入查询。这种写法下ORM无法识别字符串内部的动态内容边界，也就无法对动态部分做针对性的安全处理，一旦项目存在ORM配置不全、版本兼容导致转义失效的问题，攻击者就可以通过构造特殊的$id值直接触发SQL注入。
• 就算ORM的自动转义逻辑正常生效，这种拼接写法也存在非预期的逻辑风险：因为$id是直接嵌入正则规则的，没有做独立的输入校验，攻击者可以传入正则通配符类的内容（比如.*），让原本精确匹配ID的逻辑变成匹配所有记录，造成越权数据泄露。同时当前的REGEXP规则本身存在业务bug——没有匹配ID之间的分隔符，只要字段值中包含目标数字串就会被命中，比如查询ID=1时，存储值为21,34的记录也会被错误匹配。
• 结合项目同时使用Zend框架的技术栈特征，这类混合架构项目通常搭建时间较早，存在ORM配置不规范、自动转义覆盖不全的概率更高，实际的注入风险比新版本纯CakePHP项目要大得多。

合规修复方案 #

• 输入层强校验：因为业务场景下ID本身就是纯数字类型，先对$id做强类型校验，不通过就直接拦截请求，从入口阻断非法内容。
• 优先从查询逻辑层面消除拼接需求：当前用REGEXP匹配数字边界的写法本身性能较差，针对protocol_ids存储逗号分隔ID列表的场景，使用FIND_IN_SET函数可以完全避开正则拼接的问题，还能同时解决原正则的业务匹配bug：

// 校验ID为纯数字
if (!ctype_digit((string)$id)) {
    throw new \InvalidArgumentException("无效的Protocol ID");
}
$linkedStudies = $this->LinkedStudies->find('all')
    ->where([
        'is_citation' => true,
        'FIND_IN_SET(:id, protocol_ids)'
    ])
    ->bind(':id', (int)$id, 'integer');

• 如果业务上确实需要使用REGEXP做匹配，必须将拼接了$id的正则模式作为独立绑定参数传入，不能把硬编码的正则拼接字符串直接写在where条件里，同时要保证绑定的参数类型设置为整数，从根本上规避注入和逻辑越权的风险。

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