PHP PDO在Informix SQL的UPPER函数条件下参数绑定失效及注入安全问题

故障根因 #

• 当查询直接以name原字段作为LIKE匹配条件时，PDO配套的Informix ODBC驱动可以直接读取字段元数据，自动将绑定参数匹配为lvarchar(-1)兼容类型，因此能正常运行。
• 当匹配条件改为对字段套UPPER()函数后，预处理阶段驱动无法从函数返回值反向获取原字段的元数据，会默认将绑定参数推断为Informix不兼容的变长字符串类型，和字段实际的lvarchar(-1)类型不匹配，最终触发-11064号“SQL data type out of range”错误，属于Informix 12.10配套ODBC驱动的类型推断适配缺陷。

可落地的解决方法 #

• 方法1：绑定参数时手动指定类型与长度，关闭驱动的自动推断逻辑
  不再通过execute()批量传参，改用bindParam()显式声明参数为字符串类型、长度匹配字段上限1024，代码示例：

  $string = 'TEST';
  $search_string = $string . '%';
  $sql = 'SELECT * FROM companies WHERE UPPER(name) LIKE ? LIMIT 1';
  $query = $pdo->prepare($sql);
  // 显式指定参数类型为字符串，长度匹配字段最大值
  $query->bindParam(1, $search_string, PDO::PARAM_STR, 1024);
  $query->execute();
  $result = $query->fetchAll(PDO::FETCH_ASSOC);
  

• 方法2：在SQL语句中对绑定参数做显式类型转换
  在预处理阶段就明确告知驱动参数的目标类型，绕开自动推断逻辑，修改后的SQL为：

  $sql = 'SELECT * FROM companies WHERE UPPER(name) LIKE CAST(? AS LVARCHAR(1024)) LIMIT 1';
  

  这种方式不需要调整原有绑定参数的代码逻辑，只需要在SQL层明确类型声明即可。

现有实现的安全性判断 #

这种手动将单引号替换为双单引号再拼接进SQL的实现，*在常规配置下能阻挡大部分基础SQL注入攻击，但本质不属于参数化查询，存在明确的安全隐患：

• 转义规则强依赖数据库配置：如果Informix开启了DELIMIDENT配置（将双引号作为标识符边界而非字符串边界）、或关闭了标准字符串转义规则，原有的单引号转义逻辑会直接失效，可被注入绕过。
• 存在宽字节注入风险：当数据库连接使用GBK等多字节字符集时，手动转义单引号的逻辑可能被合法字节序列截断，导致注入点暴露。
• 维护风险高：后续迭代时如果新增拼接参数，很容易遗漏转义步骤，直接产生可利用的注入漏洞。

调整方向 #

• 优先选择参数化查询方案：使用问题1中提到的两种适配方法，通过正规参数绑定实现带UPPER(name)的查询，从根源上杜绝注入风险，不要长期依赖字符串拼接的实现。
• 如果受驱动限制必须使用拼接逻辑，将手动单引号替换的转义逻辑替换为PDO自带的quote()方法完成转义。quote()会自动适配当前驱动的转义规则、字符集配置，返回的内容已经包含了包裹字符串的单引号、完成了对应规则的转义，不需要再手动拼接单引号符号，比手动实现的转义逻辑可靠得多。修改后的代码示例：

  $string = 'TEST';
  $search_string = $pdo->quote($string . '%');
  $sql = "SELECT * FROM companies WHERE UPPER(name) LIKE $search_string LIMIT 1";
  $query = $pdo->prepare($sql);
  $query->execute();
  

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