关于mysql的sql注入问题

防注入的代码大家应该都知道，这里不做讨论

问题：应该把防注入的代码加在什么地方？

1. 加在post或get的入口？
2. 加在业务层？

请回答问题的能够举出具体的实利，不要随便搜索的内容，该搜索查询的都已经搜索了，比如yii等常用框架

回复内容：

防注入的代码大家应该都知道，这里不做讨论

问题：应该把防注入的代码加在什么地方？

1. 加在post或get的入口？
2. 加在业务层？

请回答问题的能够举出具体的实利，不要随便搜索的内容，该搜索查询的都已经搜索了，比如yii等常用框架

在数据库操作层，用参数绑定方式操作数据库，就可以防止SQL注入了

这是个特别纠结的问题,很难统一处理,应该根据具体场景检测,有些论坛用了某数字的网站卫士,用户在提交汗有sql关键字的文章的时候会被拦截–!

需要检测的地方应该都是外部接收的参数(有些从数据库取出的数据也要检测,详情可搜索二次注入),这些参数若是用作查询类型的,通常不会太过复杂,我们可以判断类型,长度等来限制,而插入型的数据则比较难处理了,dedecms的处理就是一个典型的例子,看似非常严格的检测函数,被黑客巧妙的绕过了0.0http://wenku.baidu.com/view/817d8fa1f524ccbff1218468.htmlhttp://www.2cto.com/Article/201211/168317.html

我个人的处理方法：

1. post去html化[数据本身要求干净]或者html转义化【需要html】
2. 入库前统一防止sql注入式攻击：算是model层，数据如果是int则int，如果是字符串则处理单引号问题
3. 谁展现谁处理，适用于存入库里的东西要是html片段，如果要用在javascript里面，则要展现时去html

总结来说就是：一切往前处理。 跟缓存原则很像

这套逻辑没形成之前，傻傻的从前端到后段

4本文￥来源gao!%daima.com搞$代*!码$网9

搞代gaodaima码

入库到展现，每个路上都做了防止注入，导致一大堆判断，自己累得半死。

喜欢 (0)赏

[搞代码]

分享 (0)