2021年，SQL注入死透了么？-黑客24小时在线接单网站

本文转载自微信公众号「 *** 姐味道」，小妹妹养的狗。转载本文请联系小妹妹味道微信官方账号。

长期以来，我认为后端开发在安全性方面最容易出现问题SQL注入。通过 where 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中的魔幻符号，但好在只有两种情况。

比如下面这个xml配置，就是一个绝对安全的写法。因为整个#{id}它将被取代。

<selectid="queryAll"resultMap="resultMap">

SELECT*FROMorderWHEREid=#{id}

</select>

但不幸的是，有些场景不能使用预编译（或者你只是不知道或懒惰）。例如，当一些代码重建、表名/列名/排等字段动态传输时，必然需要SQL拼接方式，SQL注入仍有搞头。

但更容易出现问题的是，LIKE和IN类似的句子。

下面是两句Like实际测试会发现模糊查询的写作 *** 是使用的#不好用，会报错，需要用sql拼接的$。这就是问题所在。

SELECT*FROMorderWHEREnamelike'%#{name}%//会报告语法错误

SELECT*FROMorderWHEREnamelike'%${name}%'//可以运行

正确的写作 *** 应该用函数拼接。然而，工期压死了人。不知不觉中，大多数人选择了简单的写作 *** 。毕竟，之一个功能也是反映工作量的主要方式。

SELECT*FROMorderWHEREnamelikeconcat(‘%’,#{name},‘%’)//正确的写作 ***

同样的问题存在于IN语句。

in(#{tag})//报错

in(${tag})//可以运行

既然几个字符可以操作，当然没有人选择以下复杂的写作 *** 。

tagin

<foreachcollection="tag"item="item"open="("separatosr=","close=")">

#{tag}

</foreach>

还有order by，不要掉以轻心，一不小心就会万劫不复。

SELECT*FROMorderorderbycreateDate#{sortType}//报错

SELECT*FROMorderorderbycreateDate${sortType}//正常

这种情况下，就需要把sortType做白名单。不只是一个。ASC和DESC好吧，你给我传了一根长串。怎么回事？

总结

SQL2021年注入仍然存在，但门槛提高了。SQL减少注入是框架的功劳，与程序员的水平无关。sql拼接永远不会消失，因为这是最快最简单的方式，会让人欲罢不能。无数的外包项目，十几年的躺尸体系统随处可见，希望在框架层消除SQL注入，是想。

因为它的对手是人性的懒惰。没有人能战胜它。

黑客24小时在线接单网站