扫码关注官方订阅号
防注入的代码大家应该都知道,这里不做讨论
问题:应该把防注入的代码加在什么地方?
请回答问题的能够举出具体的实利,不要随便搜索的内容,该搜索查询的都已经搜索了,比如yii等常用框架
人生最曼妙的风景,竟是内心的淡定与从容!
在数据库操作层,用参数绑定方式操作数据库,就可以防止SQL注入了
这是个特别纠结的问题,很难统一处理,应该根据具体场景检测, 有些论坛用了某数字的网站卫士,用户在提交汗有sql关键字的文章的时候会被拦截--!
需要检测的地方应该都是外部接收的参数(有些从数据库取出的数据也要检测,详情可搜索二次注入),这些参数若是用作查询类型的,通常不会太过复杂,我们可以判断类型,长度等来限制,而插入型的数据则比较难处理了,dedecms的处理就是一个典型的例子,看似非常严格的检测函数,被黑客巧妙的绕过了0.0 http://wenku.baidu.com/view/817d8fa1f524ccbff1218468.html http://www.2cto.com/Article/201211/168317.html
我个人的处理方法:
总结来说就是:一切往前处理。 跟缓存原则很像
这套逻辑没形成之前,傻傻的从前端到后段入库到展现,每个路上都做了防止注入,导致一大堆判断,自己累得半死。
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
PHP学习
技术支持
返回顶部
在数据库操作层,用参数绑定方式操作数据库,就可以防止SQL注入了
这是个特别纠结的问题,很难统一处理,应该根据具体场景检测, 有些论坛用了某数字的网站卫士,用户在提交汗有sql关键字的文章的时候会被拦截--!
需要检测的地方应该都是外部接收的参数(有些从数据库取出的数据也要检测,详情可搜索二次注入),这些参数若是用作查询类型的,通常不会太过复杂,我们可以判断类型,长度等来限制,而插入型的数据则比较难处理了,dedecms的处理就是一个典型的例子,看似非常严格的检测函数,被黑客巧妙的绕过了0.0 http://wenku.baidu.com/view/817d8fa1f524ccbff1218468.html http://www.2cto.com/Article/201211/168317.html
我个人的处理方法:
总结来说就是:一切往前处理。 跟缓存原则很像
这套逻辑没形成之前,傻傻的从前端到后段入库到展现,每个路上都做了防止注入,导致一大堆判断,自己累得半死。