MySQL データベースについて考えてみましょう (重要な場合)。
4478 次
7 に答える
17
いいえ、完全に安全というわけではありません。他の人が述べているように、パラメータ化されたクエリは、データベースにどのようにアクセスしているかに関係なく、常に進むべき道です。
procを使えば安全だというのは、ちょっとした都市伝説です。人々がこの妄想に陥っている理由は、ほとんどの人が、コードからパラメーター化されたクエリを使用してprocを呼び出すと想定しているためだと思います。しかし、そうでない場合、たとえば以下のようなことをする場合、あなたは広く開かれています：
SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();
エンドユーザーからのフィルタリングされていないコンテンツを使用しているためです。繰り返しになりますが、彼らがしなければならないのは、行を終了し（ ";"）、危険なコマンドを追加し、ブームを起こすことです。
（余談ですが、Webを使用している場合は、ブラウザーのクエリ文字列からフィルター処理されていないジャンクを取得しないでください。これにより、データに対して非常に悪いことを行うのが非常に簡単になります。）
クエリをパラメータ化すると、はるかに良い状態になります。ただし、ここで他の人が言及しているように、プロシージャがまだ動的SQLを生成して実行している場合は、問題が発生する可能性があります。
私は反procではないことに注意する必要があります。Procsは、データアクセスに関する特定の問題を解決するのに非常に役立ちます。しかし、procsは「SQLインジェクションに対する銀の弾丸ソリューション」ではありません。
于 2008-10-27T13:57:28.013 に答える
17
パラメータ化されたクエリを一貫して使用する場合にのみ、SQL インジェクションの影響を受けません。どこでも適切なエスケープを使用すれば、SQL インジェクションの影響をほとんど受けません (ただし、エスケープ ルーチンにはバグが存在する可能性があり、実際に存在していたため、パラメーターほど確実ではありません)。
ストアド プロシージャを呼び出し、連結によって引数を追加する場合、入力フィールドの 1 つの末尾にランダム クエリを追加できます。たとえば、CALL CheckLogin @username='$username', @password=' がある場合$password'、直接連結された変数を表す $-things を使用すると、$password 変数を "'; DROP DATABASE; --" に変更することを妨げるものは何もありません。
明らかに、事前に入力をクリーンアップすると、SQL インジェクションの防止にも役立ちますが、クリーンアップされるべきではないデータが除外される可能性があります。
于 2008-10-27T13:46:09.127 に答える
8
ストアド プロシージャが何をするかによって異なります。パラメータに基づいて SQL を動的に生成し、その SQL を実行すると、依然として脆弱です。それ以外の場合は、問題ない可能性がはるかに高くなりますが、100% 自信があるとは言えません。
于 2008-10-27T13:45:01.080 に答える
6
いいえ。ストアド プロシージャを呼び出す SQL を作成している場合でも、ターゲットになります。
クライアント側でパラメーター化されたクエリを作成する必要があります。
于 2008-10-27T13:45:04.450 に答える
4
いいえ、ストアド プロシージャで D-SQL を引き続き使用できるため、入力を検証して制限することは、いずれにしても良い考えです。
于 2008-10-27T13:43:55.717 に答える
3
実際に脆弱なのは動的コードであり、ストアド プロシージャ内のコードやストアド プロシージャへの動的に生成された呼び出しが含まれるため、ストアド プロシージャは保証されません。
パラメータ化されたクエリと、パラメータで呼び出されるストアド プロシージャは、任意の入力を使用してコードを生成しない限り、どちらもインジェクションの影響を受けません。インジェクションに対しても脆弱ではない動的コードがたくさんあることに注意してください (動的コードの整数パラメーターなど)。
ただし、主に (100% が実際に可能かどうかはわかりませんが) ストアド プロシージャ ベースのアーキテクチャの利点は、クライアント側の動的コードに対してインジェクションをある程度 (完全ではありませんが) 防御できることです。
アプリが接続しているユーザー コンテキストには、EXEC 権限のみが付与されるため、SELECT、INSERT、UPDATE、DELETE クエリはすべて失敗します。もちろん、DROP などはとにかく許可されるべきではありません。したがって、注入はEXECの形式である必要があるため、最終的には、SPレイヤーで定義した操作のみ（任意のSQLではない）を注入することさえできます。
データベース サービスを一連のストアド プロシージャ (ソフトウェアの抽象化レイヤーなど) として定義することのその他の多くの利点には、アプリに影響を与えずにデータベースをリファクタリングできること、データベースの使用パターンをよりよく理解し監視することができることなどがあります。プロファイラー、および新しいクライアントをデプロイすることなくデータベース内で選択的に最適化する機能。
于 2008-10-27T14:06:58.680 に答える
3
さらに、きめの細かいデータベース アクセス (一般にロール ベースのアクセス制御とも呼ばれます) を使用することを検討してください。インストール後に新しいテーブルを作成する必要はありませんか? その許可を取り消します。sysdba として実行する正当な必要性はありませんか? それからしないでください！ユーザーに "DROP DATABASE" を指示する卑劣なインジェクションは、ユーザーがその権限を付与されていない場合に妨害されます。次に、心配する必要があるのは、データが漏れる SELECT ステートメントだけです。
于 2008-10-27T19:46:42.973 に答える