小编给大家分享一下怎么确定sql注入死透了，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
很长一段时间，我认为后端开发，在安全性方面最容易出问题的地方就在于sql注入。通过 where 1=1这种魔幻的sql写法，就可以很容易的对一个存在问题的系统进行攻击，以至于最终演进出sqlmap这样的神器存在。
后来的fastjson刷新了我的认知，这个框架也算是对互联网安全概念的一种推动。连不懂技术的老板，都知道fastjson快的要命，作为程序员安全理念就得到了一次提升。
为什么对sql注入情有独钟？因为开发人员和sql打交道的地方太多了。甚至有的专门开发报表的同学，写的sql行数，比写的代码行数还多！
问题是。很久很久之前，早在10年前，就有人在喊sql注入已经死掉了，但时至今日，依然有一大批的sql注入教程和sql注入的案例。
sql注入是漏洞之王，这可不是吹的。
sql注入流行的原因，就是开发人员对自己太自信了，或者使用的工具太原始了，没有经过框架层进行一次过滤。如果你用了Java界的MyBatis或者JPA，发生sql注入的可能性就变的非常的低。现在PHP也有了类似于thinkPHP一样的框架，代表着能搞的sql注入漏洞已经越来越少了。
但不代表着没有，只是门槛提高了。我们以MyBatis为例，看一下到底还能不能发生sql注入。
MyBatis依然存在sql注入
使用Mybatis的同学，第一个接触的概念，就是#和$的区别。这两个符号非常的像Shell中的魔幻符号，但好在只有两种情况。
比如下面这个xml配置，就是一个绝对安全的写法。因为整个#{id}会被替换成?。
<select id="queryAll" resultMap="resultMap">
SELECT * FROM order WHERE id = #{id}
</select>
但可惜的是，有些场景，并不能使用预编译方式（或者你仅仅是不知道或者懒）。像一些代码重构，把表名/列名/排序等字段，动态传入的时候，不可避免的就需要sql拼接的方式，sql注入依然有搞头。
但更容易发生问题的，还是LIKE和IN等类似的语句。
下面是两句Like模糊查询的写法，实际测试会发现，使用#竟然不好使了，会报错，需要使用sql拼接的$。问题由此发生。
SELECT * FROM order WHERE name like '%#{name}%' //会报语法错
SELECT * FROM order WHERE name like '%${name}%' //可以运行
而正确的写法，应该使用函数拼接。但是工期压死人，在不知不觉间，大多数人就选择了简单的写法。毕竟功能第一嘛，也是体现工作量的最主要方式。
SELECT * FROM order WHERE name like concat(‘%’,#{name}, ‘%’) //正确的写法
同样的问题，存在于IN语句。
in (#{tag}) //报错
in (${tag}) //可以运行
既然几个字符就可以运行，当然没人选择下面复杂的写法。
tag in
<foreach collection="tag" item="item" open="("separatosr="," close=")">
#{tag}
</foreach>
还有order by，也千万不要掉以轻心，一不小心就会万劫不复。
SELECT * FROM order order by createDate #{sortType} //报错
SELECT * FROM order order by createDate ${sortType} //正常
这种情况下，就需要把sortType搞成白名单了。不就一个ASC和DESC了，你给我传一个长长的串，是怎么回事?
总结
sql注入在2021年，依然存在，只不过门槛提高了。现在sql注入减少，都是框架的功劳，和程序员的水平没半毛关系。sql拼接的情况永远不会消失，因为这是最快捷简单的方式，会让人欲罢不能。无数的外包项目，十几年躺尸不动的系统比比皆是，寄希望于在框架层全部消灭sql注入，是一个梦想。
因为它的对手，是人性的懒惰。谁也无法战胜它。
以上是“怎么确定sql注入死透了”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注编程之家行业资讯频道！
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
