关于mysql的sql注入问题
程序员文章站
2024-01-01 13:35:22
...
防注入的代码大家应该都知道,这里不做讨论
问题:应该把防注入的代码加在什么地方?
- 加在post或get的入口?
- 加在业务层?
请回答问题的能够举出具体的实利,不要随便搜索的内容,该搜索查询的都已经搜索了,比如yii等常用框架
回复内容:
防注入的代码大家应该都知道,这里不做讨论
问题:应该把防注入的代码加在什么地方?
- 加在post或get的入口?
- 加在业务层?
请回答问题的能够举出具体的实利,不要随便搜索的内容,该搜索查询的都已经搜索了,比如yii等常用框架
在数据库操作层,用参数绑定方式操作数据库,就可以防止SQL注入了
这是个特别纠结的问题,很难统一处理,应该根据具体场景检测, 有些论坛用了某数字的网站卫士,用户在提交汗有sql关键字的文章的时候会被拦截--!
需要检测的地方应该都是外部接收的参数(有些从数据库取出的数据也要检测,详情可搜索二次注入),这些参数若是用作查询类型的,通常不会太过复杂,我们可以判断类型,长度等来限制,而插入型的数据则比较难处理了,dedecms的处理就是一个典型的例子,看似非常严格的检测函数,被黑客巧妙的绕过了0.0 http://wenku.baidu.com/view/817d8fa1f524ccbff1218468.html http://www.2cto.com/Article/201211/168317.html
我个人的处理方法:
- post去html化[数据本身要求干净]或者html转义化【需要html】
- 入库前统一防止sql注入式攻击:算是model层,数据如果是int则int,如果是字符串则处理单引号问题
- 谁展现谁处理,适用于存入库里的东西要是html片段,如果要用在javascript里面,则要展现时去html
总结来说就是:一切往前处理。 跟缓存原则很像
这套逻辑没形成之前,傻傻的从前端到后段入库到展现,每个路上都做了防止注入,导致一大堆判断,自己累得半死。