誰もがSQLインジェクションに精通しています。一般的な攻撃方法です。攻撃者は、「OR '1' = '1'」ステートメントなど、インターフェイスのフォーム情報またはURLにいくつかの奇妙なSQLフラグメントを入力します。そのため、このような攻撃方法を防ぐために、アプリケーションでいくつかの作業を行う必要があります。銀行ソフトウェアなどの高いセキュリティを備えた一部のアプリケーションでは、SQL注入を防ぐために、すべてのSQLステートメントをストアドプロシージャに置き換える方法を使用します。もちろん、これは非常に安全な方法ですが、私たちの日常開発ではこの厳格な方法は必要ないかもしれません。
半自動化された永続性レイヤーフレームワークとして、MyBatisフレームワークは自分で手動で書く必要があります。この時点で、もちろん、SQL注射を防ぐ必要があります。実際、MyBatisのSQLは、次のように関数と同様に、「入力 +出力」関数を持つ構造です。
<select id = "getBlogbyID" resultType = "blog" parametertype = "int"> <br> id、title、著者、コンテンツを選択します=＃{id} </select>ここで、パラメータ型は入力パラメータータイプを示し、resultTypeは出力パラメータータイプを示します。上記に応じて、SQL注入を防ぎたい場合、当然、パラメーターを入力することに一生懸命働かなければなりません。上記のコードで強調表示された部分は、入力パラメーターがSQLでスプライスされる部品です。パラメーターを渡した後、実行されたSQLステートメントを印刷すると、SQLが次のように見えることがわかります。
ID、タイトル、著者、ブログからのコンテンツを選択します。
どのパラメーターが入力されても、印刷されたSQLはこのようなものです。これは、MyBatisがプリコンパイル機能を有効にするためです。 SQLが実行される前に、上記のSQLがコンパイルのためにデータベースに送信されます。実行中、コンパイルされたSQLを直接使用し、プレースホルダー「？」を交換できます。 SQL注入は編集プロセスでのみ機能するため、この方法はSQL注入の問題を回避できます。
MyBatisはどのようにしてSQLの事前コンパイルを実現しますか？実際、フレームワークの下部では、JDBCの準備クラスが機能しています。 preatedStatementは、私たちが非常によく知っている声明のサブクラスです。そのオブジェクトには、コンパイルされたSQLステートメントが含まれています。この「準備ができた」アプローチは、セキュリティを改善するだけでなく、SQLを複数回実行するときに効率を向上させます。SQLがコンパイルされており、再度実行時にコンパイルする必要はないためです。
そうは言っても、MyBatisを使用してSQL注射を防ぐことができますか？もちろん、そうではありません。次のコードをご覧ください。
<select id = "orderblog" resulttype = "blog" parametertype = "map"> select id、title、著者、$ {orderparam} </select>慎重に観察した後、インラインパラメーターの形式は「＃{xxx}」から$ {xxx}に変更されました。パラメーター「OrderParam」を「ID」に割り当ててSQLを印刷すると、次のようになります。
ID、ID、著者、コンテンツを選択します
明らかに、これはSQL注入を防ぐことはできません。 MyBatisでは、「$ {xxx}」という形式のパラメーターがSQLコンパイルに直接参加し、射撃を防ぎます。ただし、動的なテーブル名と列名に関しては、「$ {xxx}」などのパラメーター形式のみを使用できます。したがって、注入を防ぐために、コード内のこのようなパラメーターを手動で処理する必要があります。
結論： MyBatisマッピングステートメントを書くときは、フォーマット「＃{xxx}」を使用してみてください。 「$ {xxx}」のようなパラメーターを使用する必要がある場合は、SQL注入攻撃を防ぐために手動でフィルタリングを行う必要があります。
上記は、MyBatisが編集者がもたらすSQLインジェクションを防ぐJava Persistence Layer Frameworkの完全な内容です。誰もがwulin.comをもっとサポートすることを願っています〜