SQL インジェクションは廃止されたと確信していますか?

私は長い間、バックエンド開発における最も一般的なセキュリティ問題は SQL インジェクションだと考えていました。魔法の SQL 記述方法 where 1=1 を使用すると、問題のあるシステムを簡単に攻撃でき、最終的には sqlmap のようなアーティファクトが存在するようになります。

後の fastjson は私の理解を新たにしましたが、このフレームワークはインターネット セキュリティの概念を推進するものとも言えます。テクノロジーを理解していない上司でも、fastjson が非常に高速であることを知っており、プログラマーとしては安全性の概念が向上しました。

推奨 (無料):

sql##SQL インジェクションにソフト スポットがあるのはなぜですか?開発者が SQL を扱う場所が多すぎるためです。レポート開発を専門とする学生の中には、コード行よりも多くの SQL 行を作成する人もいます。

問題は。遠い昔、早ければ 10 年前には、SQL インジェクションは死んだ、と叫ぶ人もいましたが、今日に至るまで、SQL インジェクションのチュートリアルや SQL インジェクションの事例は数多く存在します。

SQL インジェクションは脆弱性の王様ですが、これは自慢ではありません。

もちろん、この点では PHP が最も貢献しており、Java は不利な立場にあります。

SQL インジェクションが人気がある理由は、開発者が自分自身に自信を持ちすぎているか、開発者が使用するツールがあまりにも原始的であり、フレームワーク層によってフィルタリングされていないためです。 Java の世界で MyBatis や JPA を使用すると、SQL インジェクションが発生する可能性は非常に低くなります。現在、PHP には

thinkphp

に似たフレームワークがあり、SQL インジェクションの脆弱性はますます少なくなっています。

しかし、それは存在しないという意味ではなく、単にしきい値が引き上げられたことを意味します。 MyBatis を例として、SQL インジェクションが依然として発生する可能性があるかどうかを確認してみましょう。

SQL インジェクションはまだ MyBatis に存在します

Mybatis を使用する学生が最初に触れる概念は

# と

$ です＃＃ ＃ 違い。これら 2 つのシンボルはシェルの魔法のシ​​ンボルに非常に似ていますが、幸いなことに、状況は 2 つだけです。

# は、安全で信頼性の高い SQL プリコンパイルの使用を表します。

• #$
は、スプライシング方式が使用されており、SQL インジェクションの危険性があります。

• たとえば、次の XML 構成は、絶対に安全な記述方法です。

  #{id}
全体が

?

に置き換えられるためです。 <div class="code" style="position:relative; padding:0px; margin:0px;"><pre class='brush:php;toolbar:false;'>&lt;select id=&quot;queryAll&quot; resultMap=&quot;resultMap&quot;&gt; SELECT * FROM order WHERE id = #{id} &lt;/select&gt;</pre><div class="contentsignin">ログイン後にコピー</div></div>しかし、残念ながら、シナリオによっては、プリコンパイルを使用できない場合があります (または、単に知らないか怠けているだけです)。たとえば、一部のコード リファクタリングでは、テーブル名/列名/ソートなどのフィールドが動的に渡されると、必然的に SQL スプライシングが必要になり、それでも SQL インジェクションが発生します。 しかし、問題が発生する可能性が高いのは、

LIKE

や

IN

のようなステートメントです。 次は、Like ファジー クエリの 2 つの文の書き方です。実際にテストしてみると、# を使用すると使いにくく、エラーが報告されます。 SQL スプライシング

$

を使用します。ここで問題が発生します。 <div class="code" style="position:relative; padding:0px; margin:0px;"><pre class='brush:php;toolbar:false;'>SELECT * FROM order WHERE name like &amp;#39;%#{name}%&amp;#39; //会报语法错 SELECT * FROM order WHERE name like &amp;#39;%${name}%&amp;#39; //可以运行</pre><div class="contentsignin">ログイン後にコピー</div></div>これを記述する正しい方法は、関数のスプライシングを使用することです。しかし、構築期限が圧倒的に多いため、ほとんどの人は気づかないうちにシンプルな書き方を選択してしまいます。結局のところ、機能が第一であり、ワークロードを反映する最も重要な方法でもあります。 <div class="code" style="position:relative; padding:0px; margin:0px;"><pre class='brush:php;toolbar:false;'>SELECT * FROM order WHERE name like concat(‘%’,#{name}, ‘%’) //正确的写法</pre><div class="contentsignin">ログイン後にコピー</div></div>同じ問題が

IN

ステートメントにも存在します。

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

数文字で実行できるので、当然ながら以下のような複雑な書き方をする人はいません。 <div class="code" style="position:relative; padding:0px; margin:0px;"><pre class='brush:php;toolbar:false;'>tag in &lt;foreach collection=&quot;tag&quot; item=&quot;item&quot; open=&quot;(&quot;separatosr=&quot;,&quot; close=&quot;)&quot;&gt; #{tag} &lt;/foreach&gt;</pre><div class="contentsignin">ログイン後にコピー</div></div>また、次の期限までに注文してください。軽く考えないでください。そうしないと、あなたは破滅するでしょう。

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

この場合、sortType をホワイトリストに登録する必要があります。 ASC と DESC だけではありません。長い文字列が送られてきました。何が起こっていますか?

概要

SQL インジェクションは 2021 年もまだ存在しますが、しきい値は引き上げられています。現在 SQL インジェクションが減少しているのはすべてフレームワークによるものであり、プログラマーのレベルとは関係ありません。 SQL スプライシングは最も速くて簡単な方法であり、人々を中毒にさせるため、SQL スプライシングの状況は決して消えることはありません。外注案件は無数にあり、10年以上眠っているシステムも多く、フレームワーク層でのSQLインジェクションの廃止は夢のまた夢です。 相手は人間の怠惰だから。誰もそれに勝つことはできません。

以上がSQL インジェクションは廃止されたと確信していますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。