SQLストアドプロシージャは安全ですか？

Question

mysql_query（＆quot; SELECT important_data FROM users WHERE password = $ password＆quot;）などの操作を行うよりも、SQLインジェクションに対する脆弱性は低いですか？

Answer 1

これらは、あなたがしていることよりも安全です。クエリは未加工のSQLをdbにポストしています。つまり、パラメーターはsqlパラメーターとしてではなく、単純な古いsqlとして扱われます。

これが私の意味です。

ストアドプロシージャでは、パスワード変数をsqlにすることはできません。システムが探している情報の一部である必要があります。あなたの例では、実際にデータベースに送信されるのは

です

SELECT * FROMパスワード=（「ここのパスワード」-$ Password変数）のユーザー。だから誰かが次のようなことをすることができます

SELECT * FROMユーザーWHEREパスワード=（ 'ここのパスワード'; SELECT * FROMユーザー-$ password変数）。

またはさらに悪い：

SELECT * FROM WHERE WHERE Password =（ 'your password here'; DROP Database Database_Name-$ password variable）。

入力パラメーターが追加のsqlとして実行されないため、非動的sqlストアドプロシージャではこれが許可されません。

Parametrized SQLはこれを処理しますが、テーブル内の情報にアクセスするユーザーは読み取りアクセスを必要としないため、技術的にはストアドプロシージャの方が少し安全です。ストアドプロシージャを実行できる必要があるだけです。必要に応じて、これは機能する場合と機能しない場合があります。

Answer 2

必ずしもそうではありませんが、その内部で文字列の連結を行っていても、露出は同じになります。パラメータ変数を使用して動的SQLを使用する場合（SQLを生成するための文字列連結はありません）、十分に保護されます。

Answer 3

パラメータを使用し、ユーザーが入力した値に文字列連結を使用しない限り、SQLインジェクションのリスクはありません。ストアドプロシージャは少し「安全」です。この側面では、パラメータを使用することを推奨しているためです。しかし、手順の中で次のようなことをした場合

EXECUTE 'SELECT important_data FROM users WHERE password = ' + @password

その後、スクエア1に戻り、SQLインジェクションに対して非常に脆弱になります。

また、「準備済みのステートメント」などもあります。ストアドプロシージャではありませんが、パラメータを使用することもできます。したがって、SQLインジェクションを回避するためにも使用できます。

Answer 4

安全な技術はありません。テクノロジーは安全な方法または安全でない方法でのみ使用できます。

とはいえ、ストアドプロシージャでは、SQLインジェクションを許可するためにわずかに創造的なコーディングが必要ですが、それでも起こります。私が知っているSQLデータベースエンジンでは、文字列を連結することを妨げるものは何もありません。

Answer 5

それらが正しくパラメーター化されており、動的SQLを実行していない場合、より安全であり、実行計画の再利用からも恩恵を受けます