如何判断SQL查询是否存在SQL注入风险及安全防护建议咨询

你改造后的写法完全没有规避SQL注入风险，两种写法本质都是本地字符串拼接：
原始写法是用f-string直接把start_time拼入SQL：

f"SELECT FIELDS(ALL) from xxxx WHERE CreatedDate >= {start_time}"

你改造后的写法用%做字符串格式化，和f-string效果完全一致，还是先在本地把参数拼到SQL字符串里再发送，只要start_time包含恶意构造的SQL片段，就会触发注入。比如start_time取值为'2024-01-01' OR 1=1 --，拼接后的SQL会变成：

SELECT FIELDS(ALL) from xxxx WHERE CreatedDate >= '2024-01-01' OR 1=1 --'

直接返回全表数据，注入成功。

如何判断是否规避了SQL注入风险？ #

可以从三个维度判断：

• 确认参数是否和SQL模板独立传输：只有当你把带占位符的SQL模板、参数值分成两个独立的字段传给第三方API，而非本地拼接成完整SQL再发送，才有可能规避注入。
• 确认第三方API是否实现了参数化查询逻辑：占位符的替换必须由API侧在数据库驱动层完成，驱动会自动对参数做转义处理，不会把参数内容识别为SQL语法的一部分。
• 做恶意注入测试：构造包含SQL特殊字符的测试参数（比如包含单引号、OR 1=1、UNION、注释符--等内容）代入查询，如果返回结果不符合预期（比如返回了全表数据、额外的其他表数据），就说明仍然存在注入风险。

该场景下的SQL注入防护建议 #

• 优先对接参数化查询接口：要求第三方API提供支持参数化查询的调用方式，你只需要传带占位符的SQL模板和参数列表，不要自己拼接SQL字符串，这是目前最可靠的防护方案。
• 若第三方仅支持传完整SQL，做严格的参数校验和转义：
  • 对于日期类型的start_time，强制校验输入格式是否符合预期的时间格式，不符合直接拦截，不允许后续执行
  • 所有用户可控的参数按照目标数据库的语法规则做转义，比如单引号替换为两个单引号，转义%、_、;、--等特殊字符
• 最小权限约束：要求第三方侧为该查询分配最小权限的数据库账号，仅开放xxxx表的查询权限，禁止增删改、禁止访问其他业务表，就算发生注入也能缩小泄露范围。
• 精简查询逻辑：不要使用FIELDS(ALL)这种返回全字段的写法，明确指定需要查询的字段，尽可能限制单次查询返回的最大行数，降低信息泄露风险。
• 禁止用户可控的SQL结构：表名、字段名、排序规则、查询逻辑等不要从用户输入中获取，只能从本地可控的枚举值中选择。

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