为什么包含'or的字符串在AJAX调用中经.serialize()处理后验证失败

问题根因 #

你遇到的是Web应用防火墙(WAF)的SQL注入防护规则误拦截。'or是经典SQL注入payload（比如' or 1=1--）的特征前缀，绝大多数WAF的默认规则都会匹配到该特征后直接拦截请求，请求根本不会到达业务控制器层，所以你前端修改序列化逻辑、替换字符都没有效果，而O'Sullivan没有'or特征，就不会被拦截。

验证方法 #

• 直接在后端服务的本地内网环境提交D'oreily测试，如果本地可以正常提交，即可确认是公网入口的WAF拦截。
• 查看WAF的拦截日志，能直接看到命中的SQL注入防护规则，特征值就是'or（规则通常大小写不敏感，所以大小写组合都会触发）。

解决方案 #

方案1：调整WAF规则（最优） #

如果WAF是你方可控的（比如云厂商WAF、服务器部署的ModSecurity等）：

• 针对该表单提交的接口添加规则例外，仅放行该接口下指定参数（比如姓名参数）的'or合法字符串，不要全局放开规则避免降低安全防护能力。
• 也可以适当调低对应接口的SQL注入检测阈值，减少对正常业务内容的误拦截。

方案2：参数编码提交 #

如果暂时无法调整WAF规则，可以前端对敏感参数编码后提交，服务端接收后解码即可：

// 前端单独编码姓名类敏感参数
let formData = $("form").serializeArray();
formData.forEach(item => {
  // 替换为你实际的姓名字段名，也可以全量参数都做编码
  if(item.name === 'user_name') {
    item.value = encodeURIComponent(item.value);
  }
});
$.ajax({
  // 其余ajax配置不变
  data: $.param(formData)
})

服务端接收到参数后做对应解码操作，就能拿到原始输入内容。

方案3：占位符替换（临时应急） #

如果编码改造成本高，可以用业务中不可能出现的特殊字符组合作为占位符做前后端替换：

• 前端提交前把单引号替换为占位符，比如 value.replace(/'/g, '__QUOTE__')
• 服务端接收到参数后再把占位符替换回单引号即可。

该方案仅适合临时应急，长期还是建议优先调整WAF规则，避免后续其他SQL注入特征字符串也被误拦截。

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