首頁 >後端開發 >php教程 >关于mysql的sql注入问题

关于mysql的sql注入问题

WBOY
WBOY原創
2016-06-06 20:50:00990瀏覽

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

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

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

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

回复内容:

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

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

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

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

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

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

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

我个人的处理方法:

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

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

这套逻辑没形成之前,傻傻的从前端到后段入库到展现,每个路上都做了防止注入,导致一大堆判断,自己累得半死。

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn