为何ESAPI编码器生成的Oracle SQL报ORA-00907缺失右括号错误？

问题现象 #

• ESAPI Oracle codec生成的动态SQL：

  SELECT * FROM EX_TABLE WHERE START_DATE = TO_DATE(''11-Jan-22'',''DD-MM-YY');
  

• 执行时触发错误：ORA-00907: missing right parenthesis
• 移除多余单引号后查询正常：

  SELECT * FROM EX_TABLE WHERE START_DATE = TO_DATE('11-Jan-22','DD-MM-YY');
  

错误原因 #

ESAPI的Oracle codec会把字符串中的单引号'转义为''——这是Oracle SQL中字符串常量的标准转义规则，但这个逻辑被错误地应用到了TO_DATE函数的参数上：

• 当Oracle解析转义后的SQL时，''会被识别为单个'，导致TO_DATE的参数结构完全混乱。原本两个独立的字符串参数'11-Jan-22'和'DD-MM-YY'，转义后变成了''11-Jan-22''和''DD-MM-YY''，Oracle无法正确识别函数的参数边界和闭合括号，因此抛出缺失右括号的错误。
• 核心问题是ESAPI的全局转义逻辑没有区分“普通字符串常量”和“函数参数内的字符串”，导致函数调用的语法被破坏。

解决方法 #

1. 改用预编译语句（PreparedStatement）：这是防范SQL注入的最优方案，完全不需要依赖ESAPI的字符串转义。示例代码：

   String sql = "SELECT * FROM EX_TABLE WHERE START_DATE = TO_DATE(?, ?)";
   PreparedStatement stmt = connection.prepareStatement(sql);
   stmt.setString(1, "11-Jan-22");
   stmt.setString(2, "DD-MM-YY");
   ResultSet rs = stmt.executeQuery();
   

2. 调整ESAPI编码范围：如果必须拼接SQL，不要对TO_DATE函数内的参数进行转义，只对SQL语句中的普通字符串常量使用ESAPI编码。
3. 升级ESAPI版本：部分旧版本的ESAPI Oracle codec存在此类场景的转义bug，升级到最新稳定版可能解决问题。

内容的提问来源于stack exchange，提问作者Rashmi Ranjan Bisoi