确定SQL注入死透了么？
很长一段时间，我认为后端开发，在安全性方面最容易出问题的地方就在于SQL注入。通过 where 1=1这种魔幻的SQL写法，就可以很容易的对一个存在问题的系统进行攻击，以至于最终演进出sqlmap这样的神器存在。
后来的fastjson刷新了我的认知，这个框架也算是对互联网安全概念的一种推动。连不懂技术的老板，都知道fastjson快的要命，作为程序员安全理念就得到了一次提升。
推荐（免费）：sql
为什么对sql注入情有独钟？因为开发人员和SQL打交道的地方太多了。甚至有的专门开发报表的同学，写的SQL行数，比写的代码行数还多！
问题是。很久很久之前，早在10年前，就有人在喊SQL注入已经死掉了，但时至今日，依然有一大批的SQL注入教程和SQL注入的案例。
SQL注入是漏洞之王，这可不是吹的。
当然在这方面，PHP的贡献最大，Java甘拜下风。
SQL注入流行的原因，就是开发人员对自己太自信了，或者使用的工具太原始了，没有经过框架层进行一次过滤。如果你用了Java界的MyBatis或者JPA，发生SQL注入的可能性就变的非常的低。现在PHP也有了类似于thinkphp一样的框架，代表着能搞的SQL注入漏洞已经越来越少了。
但不代表着没有，只是门槛提高了。我们以MyBatis为例，看一下到底还能不能发生SQL注入。
MyBatis依然存在SQL注入
使用Mybatis的同学，第一个接触的概念，就是#和$的区别。这两个符号非常的像Shell中的魔幻符号，但好在只有两种情况。
#代表的是使用sql预编译方式，安全可靠$代表着使用的是拼接方式，有SQL注入的风险
比如下面这个xml配置，就是一个绝对安全的写法。因为整个#{id}会被替换成?。
发表评论