小编给大家分享一下怎么确定SQL注入死透了,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获、下面让我们一起去了解一下吧!
很长一段时间,我认为后端开发,在安全性方面最容易出问题的地方就在于SQL注入。通过<代码> 1=1> 代码这种魔幻的SQL写法,就可以很容易的对一个存在问题的系统进行攻击,以至于最终演进出<代码> sqlmap 代码>这样的神器存在。
后来的<代码> fastjson> 代码刷新了我的认知,这个框架也算是对互联网安全概念的一种推动。连不懂技术的老板,都知道fastjson <代码>快的要命> 代码,作为程序员安全理念就得到了一次提升。
为什么对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}> 代码会被替换成<代码> ?代码> .
& lt; select id=皅ueryAll",, resultMap=皉esultMap"比; SELECT *,才能得到order WHERE id =, # {id} & lt;/select>
但可惜的是,有些场景,并不能使用预编译方式(或者你仅仅是不知道或者懒)。像一些代码重构,把表名/列名/排序等字段,动态传入的时候,不可避免的就需要SQL拼接的方式,SQL注入依然有搞头。
但更容易发生问题的,还是<代码>和代码>和<代码> 代码>等类似的语句。
下面是两句像模糊查询的写法,实际测试会发现,使用<代码> # 代码>竟然不好使了,会报错,需要使用SQL拼接的<代码> 代码>美元。问题由此发生。
SELECT *,得到order WHERE name like & # 39; % #{名称}% & # 39;,,//会报语法错 SELECT *,得到order WHERE name like & # 39; % ${名称}% & # 39;,,//可以运行
而正确的写法,应该使用函数拼接。但是工期压死的人,在不知不觉间,大多数人就选择了简单的写法。毕竟功能第一嘛,也是体现工作量的最主要方式。
SELECT *,得到order WHERE , name like concat(“%”, #{名称},,' % '),//正确的写法
同样的问题,存在于<代码> 代码>语句。
拷贝(#{标签}),//报的错 拷贝(${标签}),//可以运行
既然几个字符就可以运行,当然没人选择下面复杂的写法。
tag & lt; foreach 收集=皌ag",项=癷tem",开放=?“separatosr=?“,关闭=?“比; 标签# {}, & lt;/foreach>
还有秩序,也千万不要掉以轻心,一不小心就会万劫不复。
SELECT *,得到order order by createDate # {sortType},//报的错 SELECT *,得到order order by createDate $ {sortType},//正常
这种情况下,就需要把sortType搞成白名单了。不就一个ASC和DESC了,你给我传一个长长的串,是怎么回事?
<>强总结强>
SQL注入在2021年,依然存在,只不过门槛提高了。现在SQL注入减少,都是框架的功劳,和程序员的水平没半毛关系. SQL拼接的情况永远不会消失,因为这是最快捷简单的方式,会让人欲罢不能。无数的外包项目,十几年躺尸不动的系统比比皆是,寄希望于在框架层全部消灭SQL注入,是一个梦想。