SQL 주입이 종료된 것이 확실합니까?

오랫동안 백엔드 개발에서 가장 흔한 보안 문제는 SQL 인젝션이라고 생각했습니다. where 1=1이라는 매직 SQL 작성 방법을 통해 문제가 있는 시스템을 쉽게 공격할 수 있으며, 결국 sqlmap과 같은 아티팩트의 존재로 진화할 수 있습니다. 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}会被替换成?。

<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

나중의 fastjson은 나에게 인식을 새롭게 해주었습니다. , 이 프레임워크는 인터넷 보안 개념을 홍보하는 것으로 간주될 수도 있습니다. 기술을 모르는 상사라도 fastjson이 엄청나게 빠르다는 걸 알며, 프로그래머로서 보안 개념도 좋아졌다.

추천(무료):

sql

당신이 애착을 갖는 이유는 무엇입니까? SQL 주입? 개발자가 SQL을 다루는 곳이 너무 많기 때문입니다. 보고서 개발을 전문으로 하는 일부 학생들은 코드 줄보다 SQL 줄을 더 많이 작성하기도 합니다.

질문입니다. 아주 오래전, 빠르면 10년 전만 해도 어떤 사람들은 SQL 인젝션이 죽었다고 외쳤지만, 오늘날까지도 여전히 수많은 SQL 인젝션 튜토리얼과 SQL 인젝션 사례가 존재합니다.

SQL 주입은 취약점의 왕입니다. 이것은 자랑이 아닙니다. 🎜🎜물론 이 점에서는 Java가 뒤처진 가운데 PHP가 가장 큰 기여를 했습니다. 🎜🎜SQL 주입이 인기 있는 이유는 개발자가 너무 자신감이 있거나 사용하는 도구가 너무 원시적이며 프레임워크 계층에서 필터링되지 않았기 때문입니다. Java 세계에서 MyBatis나 JPA를 사용한다면 SQL 주입 가능성은 매우 낮아집니다. 이제 PHP에는 thinkphp와 유사한 프레임워크도 있습니다. 이는 SQL 주입 취약점이 점점 줄어들고 있음을 의미합니다. 🎜🎜하지만 전혀 없다는 뜻은 아니고, 단지 기준점이 높아졌다는 뜻일 뿐입니다. MyBatis를 예로 들어 SQL 주입이 여전히 발생할 수 있는지 살펴보겠습니다. 🎜🎜🎜MyBatis에는 SQL 주입이 여전히 존재합니다🎜🎜🎜Mybatis를 사용하는 학생들이 처음 접하게 되는 개념은 #와 $의 차이입니다. 이 두 기호는 Shell의 마법 기호와 매우 유사하지만 다행히도 상황은 두 가지뿐입니다. 🎜

• 🎜#는 안전하고 신뢰할 수 있는 SQL 사전 컴파일 사용을 나타냅니다.🎜
• 🎜$는 사용을 나타냅니다. 스플라이싱 방법에는 SQL 주입의 위험이 있습니다🎜

🎜예를 들어 다음 xml 구성은 절대적으로 안전한 작성 방법입니다. 전체 #{id}가 ?로 대체되기 때문입니다. 🎜

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

🎜하지만 안타깝게도 일부 시나리오에서는 사전 컴파일을 사용할 수 없습니다(또는 모르거나 게으른 경우). 예를 들어 일부 코드 리팩토링에서는 테이블 이름/열 이름/정렬과 같은 필드가 동적으로 전달되면 필연적으로 SQL 스플라이싱이 필요하며 여전히 SQL 주입이 발생합니다. 🎜🎜그러나 LIKE 및 IN과 같은 유사한 문은 문제를 일으킬 가능성이 더 높습니다. 🎜🎜다음은 Like 퍼지 쿼리 두 문장을 작성하는 방법입니다. 실제 테스트에서 #를 사용하는 것이 쉽지 않고 SQL을 사용해야 한다는 것을 알 수 있습니다. $를 이어붙입니다. 여기서 문제가 발생합니다. 🎜

tag in
<foreach collection="tag" item="item" open="("separatosr="," close=")">
#{tag} 
</foreach>

🎜올바른 작성 방법은 함수 접합을 사용하는 것입니다. 하지만 공사 기한이 벅차서, 이를 깨닫지도 못한 채 대부분의 사람들은 간단한 글쓰기 방식을 선택합니다. 결국 기능이 우선이고, 작업량을 반영하는 가장 중요한 방식이기도 합니다. 🎜

SELECT * FROM order order by createDate #{sortType} //报错
SELECT * FROM order order by createDate ${sortType} //正常

🎜IN 문에도 같은 문제가 있습니다. 🎜rrreee🎜단 몇 글자만으로 실행이 가능하기 때문에 당연히 아래의 복잡한 작성 방법을 선택하는 사람은 없습니다. 🎜rrreee🎜주문도 가볍게 여기지 마세요. 그렇지 않으면 위험에 처하게 됩니다. 🎜rrreee🎜이 경우 sortType을 화이트리스트에 추가해야 합니다. ASC, DESC 뿐만 아니라 긴 문자열을 보냈는데 무슨 일이죠? 🎜🎜🎜Summary🎜🎜🎜SQL 주입은 2021년에도 여전히 존재하지만 임계값이 높아졌습니다. 이제 SQL 주입이 감소한 것은 모두 프레임워크 때문이며 프로그래머 수준과는 아무런 관련이 없습니다. SQL 스플라이싱의 상황은 가장 빠르고 쉬운 방법이며 사람들을 중독시킬 것이기 때문에 결코 사라지지 않을 것입니다. 아웃소싱 프로젝트도 셀 수 없이 많고, 10년 넘게 휴면상태에 있는 시스템도 많아 프레임워크 계층에서 SQL 인젝션이 사라지길 바라는 것도 꿈이다. 🎜🎜그의 상대는 인간의 게으름이기 때문이죠. 누구도 그것을 이길 수 없습니다. 🎜

위 내용은 SQL 주입이 종료된 것이 확실합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!