web后台防sql注入的困惑

Question

最近安全组的同事给我们提了一个sql注入的高危漏洞，
跟同事一起看了代码，发现对于前段传入进来的字符串参数未做严格的合法性检测，
于是我们开始动手修复这个漏洞，然后就产生了分歧，

同事认为，对前段所有的字符串类型的参数都做检测，且他写的检测逻辑非常严格，如下：
1.根据项目需要仅支持部分特殊字符，2.通过正则表达式匹配是否包含所有的mysql关键字，如果包含则认为该参数不合法。

我觉得仅针对要拼接到sql语句中的字符串类型参数做检查就好了，为什么要检查所有的字符串类型参数？

请问各位大神，我的同事的做法是否不太合理呢？你们是怎样在代码中防御sql注入的呢？

谢谢！

Answer 1

防注入的任务：屏蔽sql参数导致的非法执行。我认为还是应该将验证前置，所有后台接收的参数、信息字段都是有预期模型的，从安全、严谨、业务信息准确等角度，对不符合期望的数据类型，都应该检查，并隔离。并反馈相应的提示消息。

Answer 2

直接参数化，拼接sql直接传值实际上就是一种懒惰的编程习惯

Answer 3

為了防止SI，針對會進入SQL的參數做檢測，這個方向沒有錯
但沒有進入SQL的參數就不檢測嗎？這蠻值得討論的
我認為，檢測可以做在進入SQL之前，而不是做在API入口
這樣既確保所有進入SQL的參數都通過檢測，也不會因為檢測多餘的參數浪費效能或時間
而未被檢測的參數如果有一天也需要進入SQL，避不了一定要經過檢測層，這樣就不怕將來增加參數時出現遺漏

Answer 4

我认为你和他做的都不合理，如果前端传来了MySQL关键字字符串，难道要拒绝存储吗。我觉得应该釜底抽薪：直接使用参数话的SQL就好了。

Answer 5

直接参数化防止sql注入，问题的描述可以拆分成两点看待，一个是从业务上验证参数的合法性，一个是防止sql注入。.Net框架提供模型校验，属性如[Required]、[ RegularExpression]的设计都是满足业务需求上的验证的，防sql注入是系统框架安全需求。实际业务中很大可能存在符合业务参数的需求但是作为字符串拼接sql时异常的场景，比如客户提交的参数中包含富文本内容。