Sind Sie sicher, dass die SQL-Injection tot ist?

Lange Zeit dachte ich, dass das häufigste Sicherheitsproblem in der Backend-Entwicklung die SQL-Injection sei. Durch die magische SQL-Schreibmethode where 1=1 können Sie ein problematisches System leicht angreifen und schließlich zur Existenz von Artefakten wie sqlmap führen. 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

Das spätere fastjson hat meine Erkenntnis aufgefrischt Dieser Rahmen kann auch als Förderung des Konzepts der Internetsicherheit angesehen werden. Selbst Chefs, die sich nicht mit Technik auskennen, wissen, dass Fastjson extrem schnell ist, und als Programmierer wurde das Sicherheitskonzept verbessert.

Empfohlen (kostenlos):

sql

Warum haben Sie eine Schwäche für SQL-Injektion? Denn es gibt zu viele Stellen, an denen sich Entwickler mit SQL befassen. Einige Studenten, die sich auf die Entwicklung von Berichten spezialisiert haben, schreiben sogar mehr Zeilen SQL als Codezeilen!

Die Frage ist. Vor langer Zeit, bereits vor 10 Jahren, riefen einige Leute, dass SQL-Injection tot sei, aber bis heute gibt es immer noch eine große Anzahl von SQL-Injection-Tutorials und SQL-Injection-Fällen.

SQL-Injection ist der König der Schwachstellen, das ist keine Prahlerei. 🎜🎜Natürlich hat PHP in dieser Hinsicht den größten Beitrag geleistet, während Java zurückfiel. 🎜🎜Der Grund, warum SQL-Injection beliebt ist, liegt darin, dass Entwickler zu selbstsicher sind oder die von ihnen verwendeten Tools zu primitiv sind und nicht von der Framework-Ebene gefiltert wurden. Wenn Sie MyBatis oder JPA in der Java-Welt verwenden, wird die Möglichkeit einer SQL-Injection sehr gering. Jetzt verfügt PHP auch über ein Framework, das thinkphp ähnelt, was bedeutet, dass es immer weniger SQL-Injection-Schwachstellen gibt. 🎜🎜Aber das heißt nicht, dass es keine gibt, es bedeutet nur, dass die Schwelle angehoben wurde. Nehmen wir MyBatis als Beispiel, um zu sehen, ob noch eine SQL-Injection erfolgen kann. 🎜🎜🎜SQL-Injection gibt es immer noch in MyBatis🎜🎜🎜Studenten, die Mybatis verwenden, das erste Konzept, mit dem sie in Berührung kommen, ist der Unterschied zwischen # und $. Diese beiden Symbole sind den magischen Symbolen in Shell sehr ähnlich, aber glücklicherweise gibt es nur zwei Situationen. 🎜

• 🎜# stellt die Verwendung der SQL-Vorkompilierung dar, die sicher und zuverlässig ist🎜
• 🎜$ stellt die Verwendung dar Bei der Spleißmethode besteht die Gefahr einer SQL-Injection🎜

🎜Beispielsweise ist die folgende XML-Konfiguration eine absolut sichere Schreibweise. Weil der gesamte #{id} durch ? ersetzt wird. 🎜

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

🎜Aber leider kann in manchen Szenarien die Vorkompilierung nicht verwendet werden (oder Sie wissen es einfach nicht oder sind faul). Beispielsweise ist bei einigen Code-Refactorings, wenn Felder wie Tabellennamen/Spaltennamen/Sortierung dynamisch übergeben werden, zwangsläufig SQL-Spleißen erforderlich, und es kommt immer noch zu einer SQL-Injection. 🎜🎜Aber ähnliche Anweisungen wie LIKE und IN verursachen eher Probleme. 🎜🎜Im Folgenden erfahren Sie, wie Sie zwei Sätze einer Like-Fuzzy-Abfrage schreiben. Bei tatsächlichen Tests wird festgestellt, dass die Verwendung von # nicht einfach ist und ein Fehler gemeldet wird Spleißen von $. Hier entsteht das Problem. 🎜

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

🎜Die richtige Art, es zu schreiben, ist die Verwendung von Funktionsspleißen. Aber die Baufrist ist überwältigend und ohne es zu merken, entscheiden sich die meisten Menschen für die einfache Schreibweise. Schließlich steht die Funktion an erster Stelle und ist auch die wichtigste Art, die Arbeitsbelastung widerzuspiegeln. 🎜

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

🎜Das gleiche Problem besteht in der IN-Anweisung. 🎜rrreee🎜Da es mit nur wenigen Zeichen ausgeführt werden kann, wählt natürlich niemand die untenstehende komplizierte Schreibmethode. 🎜rrreee🎜Bestellen Sie auch bis, nehmen Sie es nicht auf die leichte Schulter, sonst geraten Sie in Gefahr. 🎜rrreee🎜In diesem Fall müssen Sie sortType auf die Whitelist setzen. Es sind nicht nur ASC und DESC. Sie haben mir eine lange Zeichenfolge geschickt. Die Reduzierung der SQL-Injection ist jetzt allein auf das Framework zurückzuführen und hat nichts mit dem Niveau der Programmierer zu tun. Die Situation des SQL-Spleißens wird niemals verschwinden, da es der schnellste und einfachste Weg ist und die Menschen süchtig danach machen wird. Es gibt unzählige Outsourcing-Projekte, und es gibt viele Systeme, die seit mehr als zehn Jahren brachliegen. Es ist ein Traum zu hoffen, dass die SQL-Injection auf der Framework-Ebene eliminiert wird. 🎜🎜Denn sein Gegner ist die menschliche Faulheit. Niemand kann es besiegen. 🎜

Das obige ist der detaillierte Inhalt vonSind Sie sicher, dass die SQL-Injection tot ist?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!