SQLインジェクション防止メカニズムがパラメーター化されたクエリを使用する方向に進化したのはなぜですか？

私の考えでは、SQLインジェクション攻撃は次の方法で防止できます。

1. 入力を慎重にスクリーニング、フィルタリング、エンコードする（SQLへの挿入前）
2. 使用して準備された文 /パラメータ化クエリを

それぞれに長所と短所があると思いますが、なぜ＃2が離陸し、インジェクション攻撃を防ぐための事実上の方法であると見なされるようになったのですか？単に安全でエラーが発生しにくいのですか、それとも他の要因がありましたか？

私が理解しているように、＃1が適切に使用され、すべての警告が処理されれば、＃2と同じくらい効果的です。

サニタイズ、フィルタリング、エンコード

私の側では、サニタイズ、フィルタリング、およびエンコードの意味が混乱していました。この場合、サニタイズとフィルタリングは入力データを変更または破棄する可能性があることを理解していますが、エンコードはデータをそのまま保持しますが、エンコードしますインジェクション攻撃を避けるために適切に。データをエスケープすることは、それをエンコードする方法と考えることができると信じています。

パラメータ化されたクエリとエンコーディングライブラリ

parameterized queriesとの概念がencoding libraries相互に交換可能に扱われている答えがあります。私が間違っている場合は修正しますが、私はそれらが異なっているという印象を受けています。

私が理解しているのは、encoding librariesどんなに優れていても、SQL「プログラム」を変更する可能性は常にあるということです。

Parameterized queries 一方、SQLプログラムをRDBMSに送信すると、RDBMSはクエリを最適化し、クエリ実行プランを定義し、使用するインデックスを選択するなどして、RDBMS内の最後のステップとしてデータをプラグインします。自体。

エンコーディングライブラリ

  data -> (encoding library)
                  |
                  v
SQL -> (SQL + encoded data) -> RDBMS (execution plan defined) -> execute statement

パラメータ化されたクエリ

                                               data
                                                 |
                                                 v
SQL -> RDBMS (query execution plan defined) -> data -> execute statement

歴史的意義

いくつかの回答では、歴史的に、パラメーター化されたクエリ（PQ）はパフォーマンス上の理由で作成され、インジェクション攻撃の前にエンコードの問題をターゲットにしたと言われています。ある時点で、PQはインジェクション攻撃に対しても非常に効果的であることが明らかになりました。私の質問の精神を維持するために、なぜPQが選択の方法であり続け、SQLインジェクション攻撃の防止に関して、他のほとんどの方法よりも優れているのでしょうか？

問題は、＃1では、作業対象のSQLバリアント全体を効果的に解析および解釈する必要があるため、実行すべきでないことを実行しているかどうかがわかることです。また、データベースを更新するときに、そのコードを最新の状態に保ちます。どこでもあなたのクエリの入力を受け付けます。それを台無しにしないでください。

そのため、そのようなことはSQLインジェクション攻撃を阻止しますが、実装するのはとてつもなく費用がかかります。

オプション1は解決策ではないからです。スクリーニングとフィルタリングとは、無効な入力を拒否または削除することを意味します。ただし、入力は有効かもしれません。たとえば、アポストロフィは「O'Malley」という名前の有効な文字です。SQLで使用する前に正しくエンコードする必要があります。これが準備済みステートメントの機能です。

メモを追加すると、機能的に類似した独自のコードをゼロから作成するのではなく、基本的に標準ライブラリ関数を使用する理由を尋ねているようです。独自のコードを記述するよりも、常に標準ライブラリソリューションを優先する必要があります。作業量が少なく、メンテナンスが容易です。これはどの機能にも当てはまりますが、特にセキュリティに敏感なものの場合、自分で車輪を再発明することはまったく意味がありません。

文字列処理を実行しようとしている場合、実際にはSQLクエリを生成していません。SQLクエリを生成できる文字列を生成しています。間接的なレベルがあるため、エラーやバグが発生する余地が大きくなります。ほとんどのコンテキストで、プログラムで何かとやり取りできることを考えると、本当に驚くべきことです。たとえば、リスト構造があり、アイテムを追加する場合、通常は行いません。

List<Integer> list = /* a list of 1, 2, 3 */
String strList = list.toString();   /* to get "[1, 2, 3]" */
strList = /* manipulate strList to become "[1, 2, 5, 3]" */
list = parseList(strList);

誰かがそれを提案するなら、あなたはそれはむしろばかげていると正しく答えるでしょう。

List<Integer> list = /* ... */;
list.add(5, position=2);

これは、概念レベルでデータ構造と相互作用します。その構造がどのように印刷または解析されるかに依存しません。これらは完全に直交する決定です。

最初のアプローチは最初のサンプルのようなものです（少し悪いだけです）：必要なクエリとして正しく解析される文字列をプログラムで構築できると仮定しています。これは、パーサーと、一連の文字列処理ロジックに依存します。

準備済みクエリを使用する2番目のアプローチは、2番目のサンプルによく似ています。準備されたクエリを使用する場合、基本的には正当であるがいくつかのプレースホルダーを含む擬似クエリを解析し、APIを使用してそこにいくつかの値を正しく代入します。解析プロセスに関与しなくなり、文字列処理について心配する必要はありません。

一般に、概念レベルで物事とやり取りするのははるかに簡単で、エラーが発生しにくいです。クエリは文字列ではありません。クエリは、文字列を解析するか、プログラムで構築する（または他の方法で作成できる）ときに得られるものです。

ここでは、単純なテキスト置換を行うCスタイルのマクロと、任意のコード生成を行うLispスタイルのマクロの間には良い類似性があります。Cスタイルのマクロを使用すると、ソースコード内のテキストを置き換えることができます。つまり、構文エラーや誤解を招く動作を導入することができます。Lispマクロを使用すると、コンパイラが処理する形式でコードを生成します（つまり、コンパイラが到達する前にリーダーが処理する必要のあるテキストではなく、コンパイラが処理する実際のデータ構造を返します） 。ただし、Lispマクロを使用すると、解析エラーになるようなものを生成できません。たとえば、（let（（ab）aを生成できません。

Lispマクロを使用しても、そこにあるはずの構造に必ずしも気付く必要はないため、依然として不正なコードを生成する可能性があります。たとえば、Lispでは、 （let（（ab））a）は、「変数aの変数bの値への新しい字句バインディングを確立してから、aの値を返す」ことを意味し、（let（ab）a）は「変数aとbの新しい字句バインディングを確立し、両方をnilに初期化してから、aの値を返します。」どちらも構文的には正しいですが、意味は異なります。この問題を回避するには、よりセマンティックに対応した関数を使用して、次のようなことを行うことができます。

Variable a = new Variable("a");
Variable b = new Variable("b");
Let let = new Let();
let.getBindings().add(new LetBinding(a,b));
let.setBody(a);
return let;

そのようなものでは、構文的に無効なものを返すことは不可能であり、意図しないものを誤って返すことははるかに困難です。

データベースはクエリのパラメーター化されていないバージョンをキャッシュできるため、オプション＃2は一般的にベストプラクティスと見なされます。パラメータ化されたクエリは、SQLインジェクションの問題に数年前から存在します（私は信じています）。たった1石で2羽の鳥を殺すことができます。

単純に言った：彼らはしませんでした。あなたの声明：

SQLインジェクション防止メカニズムがパラメーター化されたクエリを使用する方向に進化したのはなぜですか？

基本的に欠陥があります。パラメーター化されたクエリは、SQLインジェクションが少なくとも広く知られているよりもずっと長く存在していました。これらは一般に、LOB（基幹業務）アプリケーションが持つ通常の「検索用フォーム」機能での文字列集中を回避する方法として開発されました。多く-何年も-後に、誰かが上記の文字列操作に関するセキュリティ問題を発見しました。

25年前（インターネットが広く使用されていなかった-始まったばかり）にSQLを実行したことを覚えています。

他のすべての良い答えに加えて：

＃2が優れている理由は、コードからデータを分離するためです。＃1では、データはコードの一部であり、そこからすべての悪いことが起こります。＃1ではクエリを取得し、クエリがデータをデータとして理解するように追加のステップを実行する必要がありますが、＃2ではコードとコードであり、データはデータです。

SQLインジェクション防御を提供することとは別に、パラメーター化されたクエリには、多くの場合、一度だけコンパイルされ、異なるパラメーターで複数回実行されるという追加の利点があります。

SQLデータベースの観点から見るselect * from employees where last_name = 'Smith'とselect * from employees where last_name = 'Fisher'、明らかに異なるため、個別の解析、コンパイル、および最適化が必要です。また、コンパイルされたステートメントの保存専用のメモリ領域内の個別のスロットを占有します。異なるパラメータ計算とメモリオーバーヘッドを持つ多数の同様のクエリを使用する負荷の高いシステムでは、かなりの量になる可能性があります。

その後、パラメーター化されたクエリを使用すると、多くの場合、パフォーマンスが大幅に向上します。

待ってください、なぜですか？

オプション1は、あらゆるタイプの入力に対してサニタイズルーチンを作成する必要があることを意味しますが、オプション2は、作成/テスト/保守するためのエラーが少なく、コードが少なくなります。

ほぼ間違いなく、「すべての警告を処理する」ことは、あなたが思っているよりも複雑になる可能性があり、あなたの言語（たとえば、Java PreparedStatement）は、あなたが思っているよりも内部にあります。

準備済みステートメントまたはパラメーター化されたクエリはデータベースサーバーでプリコンパイルされるため、パラメーターが設定されている場合、クエリはSQL文字列ではないため、SQL連結は行われません。追加の利点は、RDBMSがクエリをキャッシュし、後続の呼び出しがパラメーター値が異なる場合でも同じSQLと見なされることです。一方、連結SQLでは、異なる値でクエリが実行されるたびにクエリが異なり、RDBMSはそれを解析する必要があります、実行計画を再度作成するなど。

理想的な「サニタイズ、フィルター、エンコード」アプローチがどのようになるか想像してみましょう。

サニタイズとフィルタリングは、特定のアプリケーションのコンテキストでは理にかなっているかもしれませんが、最終的には両方とも「このデータをデータベースに入れることはできません」と言うことになります。アプリケーションにとっては、それは良いアイデアかもしれませんが、データベースに任意の文字を格納する必要があるアプリケーションがあるため、一般的なソリューションとして推奨できるものではありません。

したがって、エンコードはそのままです。エスケープ文字を追加して文字列をエンコードする関数を作成することから始めて、自分で文字列を置き換えることができます。データベースごとに異なる文字をエスケープする必要があるため（一部のデータベースでは、両方ともの有効なエスケープシーケンスですが、他のデータベースではそう\'で''はあり'ません）、この機能はデータベースベンダーが提供する必要があります。

しかし、すべての変数が文字列ではありません。整数または日付に置き換える必要がある場合があります。これらは文字列とは異なる方法で表されるため、異なるエンコード方法が必要になり（再び、これらはデータベースベンダーに固有である必要があります）、さまざまな方法でクエリに置き換える必要があります。

したがって、データベースがあなたのために置換を処理した場合、おそらく物事は簡単になるでしょう-クエリが期待するタイプ、データを安全にエンコードする方法、およびクエリに安全に置換する方法をすでに知っているので、心配する必要はありませんあなたのコードで。

この時点で、パラメーター化されたクエリを再発明しました。

また、クエリがパラメータ化されると、パフォーマンスの最適化や監視の簡素化などの新しい機会が開かれます。

エンコーディングを正しく実行することは難しく、エンコーディングを正しく実行することはパラメーター化と区別できません。

あなたが本当に建物クエリの方法として、文字列の補間のように、プラグイン可能な文字列の補間を持つ言語（スカラとES2015が頭に浮かぶ）がいくつかあり、その場合はそこに ある ライブラリ、あなたは文字列の補間のように見えるパラメータ化クエリを書いてみましょうが、 SQLインジェクションから安全です-ES2015構文では：

import {sql} from 'cool-sql-library'

let result = sql`select *
    from users
    where user_id = ${user_id}
      and password_hash = ${password_hash}`.execute()

console.log(result)

オプション1では、非常に大きな出力サイズにマップしようとしているsize = infinityの入力セットを使用しています。オプション2では、入力を選択したものに制限しました。言い換えると：

1. [ すべての安全なSQLクエリ ] に対する慎重なスクリーニングとフィルタリング[ 無限大 ]
2. 使用する[ 対象範囲に限定された事前に考慮されたシナリオ ]

他の回答によると、範囲を無限から管理しやすいものに制限することで、パフォーマンス上の利点も得られるようです。

SQL（特に現代的な方言）の有用なメンタルモデルの1つは、各SQLステートメントまたはクエリがプログラムであることです。ネイティブバイナリ実行可能プログラムでは、最も危険な種類のセキュリティ脆弱性はオーバーフローであり、攻撃者は異なる命令でプログラムコードを上書きまたは変更できます。

SQLインジェクションの脆弱性は、Cなどの言語のバッファオーバーフローと同型です。歴史から、バッファオーバーフローの防止は非常に困難であることが示されています。

オーバーフローの脆弱性を解決するための最新のアプローチの重要な側面の1つは、ハードウェアとOSメカニズムを使用して、メモリの特定の部分を非実行可能としてマークし、メモリの他の部分を読み取り専用としてマークすることです。（例えば、実行可能スペース保護に関するWikipediaの記事を参照してください。）そのようにして、攻撃者がデータを変更できたとしても、攻撃者は注入されたデータをコードとして扱うことはできません。

SQLインジェクションの脆弱性がバッファオーバーフローに相当する場合、NXビットまたは読み取り専用メモリページに相当するSQLは何ですか？答えは次のとおりです。準備されたステートメントには、パラメーター化されたクエリと、クエリ以外のリクエストに対する同様のメカニズムが含まれます。準備済みステートメントは読み取り専用とマークされた特定の部分でコンパイルされているため、攻撃者はプログラムのこれらの部分、および実行不能データ（準備済みステートメントのパラメーター）としてマークされた他の部分を変更できません。プログラムコードとして扱われることはないため、悪用の可能性のほとんどが排除されます。

確かに、ユーザー入力をサニタイズすることは良いことですが、本当に安全であるためには、妄想的である必要があります（または、同様に、攻撃者のように考える必要があります）。プログラムテキストの外側のコントロールサーフェスはそれを行う方法であり、準備されたステートメントはそのコントロールサーフェスをSQLに提供します。したがって、準備されたステートメント、したがってパラメーター化されたクエリが、セキュリティ専門家の大多数が推奨するアプローチであることは驚くことではありません。

私はこのことについてここに書いています：https ://stackoverflow.com/questions/6786034/can-parameterized-statement-stop-all-sql-injection/33033576#33033576

しかし、単純にするために：

パラメータ化されたクエリが機能する方法は、sqlQueryがクエリとして送信され、データベースがこのクエリの処理内容を正確に認識し、その値が設定された場合のみユーザー名とパスワードを値として挿入することです。これは、データベースがクエリの処理内容をすでに知っているため、クエリに影響を与えることができないことを意味します。そのため、この場合、「Nobody OR 1 = 1 '-」のユーザー名と空のパスワードを検索しますが、これは間違っているはずです。

ただし、これは完全なソリューションではなく、入力検証を行う必要があります。これは、Javascriptをデータベースに入れることができるため、XSS攻撃などの他の問題には影響しないためです。次に、これがページに読み込まれると、出力検証に応じて、通常のjavascriptとして表示されます。そのため、実際に行うのに最適なのは入力検証を使用することですが、パラメーター化されたクエリまたはストアドプロシージャを使用してSQL攻撃を阻止します

SQLを使用したことはありません。しかし、明らかに、人々が抱えている問題について耳にし、SQL開発者はこの「SQLインジェクション」の問題を抱えていました。長い間、私はそれを理解できませんでした。そして、ユーザーが入力した文字列を連結することによって、SQLステートメント、実際のテキストSQLソースステートメントを作成する人々に気付きました。そして、その実現に関する私の最初の考えは衝撃でした。トータルショック。どうしてこんなにばかげてばかげて、そのようなプログラミング言語で文を作成できるのでしょうか？C、C ++、Java、Swiftの開発者にとって、これはまったくの狂気です。

ただし、C文字列を引数として取り、同じ文字列を表すCソースコードの文字列リテラルとまったく同じように見える別の文字列を生成するC関数を記述することはそれほど難しくありません。たとえば、その関数はabcを "abc"に、 "abc"を "\" abc \ ""に、 "\" abc \ ""を "\" \\ "abc \\" \ ""に変換します。（まあ、これがあなたに間違っているようであれば、それはhtmlです。それを入力したときは正しいのですが、表示されるときではありません）そして、そのC関数が書かれれば、Cソースコードを生成することはまったく難しくありません。ユーザーが入力した入力フィールドのテキストは、C文字列リテラルに変換されます。安全にするのは難しくありません。SQL開発者がSQLインジェクションを回避する方法としてそのアプローチを使用しない理由は、私を超えています。

「サニタイズ」は完全に欠陥のあるアプローチです。致命的な欠陥は、特定のユーザー入力が違法になることです。汎用テキストフィールドに;などのテキストを含めることができないデータベースになります。テーブルをドロップするか、SQLインジェクションで使用して破損を引き起こすものは何でも。私はそれをまったく受け入れられないと思います。データベースにテキストを保存する場合、任意のテキストを保存できる必要があります。そして、実用的な欠陥は、サニタイザーがそれを正しくすることができないようであるということです:-(

もちろん、パラメーター化されたクエリは、コンパイルされた言語を使用するプログラマーが期待するものです。文字列の入力があり、それをSQL文字列に変換することはありませんが、パラメータとして渡すだけで、文字列内の文字が損傷を引き起こす可能性はありません。

コンパイルされた言語を使用する開発者の観点からすると、サニタイズは私には決して起こらないものです。サニタイズの必要性は非常識です。パラメータ化されたクエリは、問題の明らかな解決策です。

（Josipの答えは興味深いものでした。基本的に、パラメーター化されたクエリを使用すると、SQLに対する攻撃を阻止できますが、JavaScriptインジェクションの作成に使用するデータベースにテキストを含めることができます:-( 、Javascriptがそれに対する解決策を持っているかどうかはわかりません。

主な問題は、パラメーター化されたクエリがパフォーマンスとメモリの追加の利点と完全に機能する既存の手順であったのに対し、ハッカーが衛生を取り囲む方法を見つけたことです。

「一重引用符と二重引用符だけ」として問題を単純化する人もいますが、ハッカーは異なるエンコーディングの使用やデータベース機能の使用など、検出を回避する賢明な方法を見つけました。

とにかく、壊滅的なデータ侵害を引き起こすには、1つの文字列を忘れるだけで済みました。スクリプトを自動化して、シリーズまたはクエリを含む完全なデータベースをダウンロードできるハッカー。ソフトウェアがオープンソーススイートや有名なビジネススイートのようによく知られている場合、ユーザーとパスワードの表を単純にアタッチできます。

一方、連結クエリを使用することは、使用方法を習得し、それに慣れるだけの問題でした。