使用ODBC {CALL}调用SQL Server存储过程能否防范SQL注入？

核心结论 #

这种写法并非真正的参数化存储过程调用，属于伪装成最佳实践的危险写法，存在明确的SQL注入风险。

具体分析 #

• ODBC {CALL}语法的本质：
  {CALL}确实是ODBC的转义语法，最终会被ODBC驱动转换为SQL Server支持的EXEC语句，但这个转换仅做语法适配，不会对拼接进字符串的参数做任何防注入预处理。你当前的写法本质上是用CString.Format把外部参数直接拼进SQL语句，和普通的字符串拼接SQL没有区别，完全依赖手工的单引号替换和长度校验来防护。

• 手工防注入的局限性：
  仅将'替换为''的防护逻辑存在明显漏洞：比如遇到字符集编码绕过（如某些双字节字符集下的单引号变种）、或者存储过程内部本身使用动态SQL时，这种替换完全失效。长度校验只能限制输入长度，但无法阻止短但有效的注入payload。

• 真正的参数化调用方式：
  使用{CALL InsertStoredProcedureXYZ(?, ?)}结合参数绑定的写法，才是ODBC规范的参数化调用。这种方式下，参数会被驱动以二进制安全的形式传递给数据库，参数内容不会被解析为SQL语句的一部分，从根源上避免了SQL注入，也不需要手工处理参数。

实践建议 #

• 优先重构高风险接口：如果无法一次性全量修改代码，先处理直接接收外部Web API输入的接口，替换为参数化绑定的写法，这是最彻底的防护方案。
• 临时强化校验（过渡方案）：在现有基础上增加字符白名单校验，只允许业务预期的字符（比如字母、数字、特定符号），但这只是临时措施，不能替代真正的参数化调用。

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