SQL インジェクションの防止

これを実行すると次のようにプロファイラに記録されます。

引用:
select * from Products where ProductID = 20 exec sp_executesql N'select * from Products where ProductID = @P1', N'@P1 int ', 30

で、私は後者の記述がキライということ。

あなたがストアドに変な固定概念を持っているだけでは？ 別にストアドのすべてがユーザープログラマブル(とそれを実行する機構)である必要はないでしょ？ SQL Server の場合、sp_executesql は拡張ストアドプロシージャとして実装されているので、内部がどうなっているのか良く分からないけど、多分、コアと密接な関係にあるのでしょう。ストアドという呼び出し形態を取る事でミドルウェアのインターフェイスがシンプルになるんじゃないかな。

一般的な処理だなんて書いてないですよ？ むしろ、私の確認できる範囲として「SQL Server の場合」と断り書きをしていることのほうが多いはずですが？

意味って何の意味ですか？ プリコンパイルによるパフォーマンス向上の恩恵は受けられませんが、十分にテストされたミドルウェアであれば、プレーンテキスト展開をしていても SQL インジェクション対策としての意味が十分あると思いますけど。

ええ、そこまでするほどの理由です。

こばさんさんの書き込み (2005-07-07 18:29) より:

　検索キーワード省略時に対応したものを作ろうとすると SQL文 が伸びるのがいやで・・・（もしくは完全にストアド化して分岐させるか）

select * from account where (uid=@uid or @uid is null) and (pas=@pas or @pas is null)

※このような認証時の例にパラメータ省略を考えるのは不適切ですけど、うーん、美しくない！って思っちゃいます。

この文脈ではパフォーマンスに触れているわけですから、パフォーマンスの観点ではパラメータクエリを使うことが無意味になってしまう、ということです。

こばさんさんの書き込み (2005-07-07 18:29) より:
　検索キーワード省略時に対応したものを作ろうとすると SQL文 が伸びるのがいやで・・・（もしくは完全にストアド化して分岐させるか）

select * from account where (uid=@uid or @uid is null) and (pas=@pas or @pas is null)

※このような認証時の例にパラメータ省略を考えるのは不適切ですけど、うーん、美しくない！って思っちゃいます。

未記入さんの書き込み (2005-07-07 19:46) より:
この文脈ではパフォーマンスに触れている？ それは、あなたの脳内だけでは？

もちろんそうですが、「プレーンテキストに展開」(ってパラメータを値に置換するってこと
ですよね?)したら意味ないですよね?

それと、(密接な関係があるのは確かですが) パフォーマンス向上の要因になっているのはパラメタを使うことではなく、プリコンパイルによるものでしょう。

スレタイもそうだし、他の人はパラメータ化による安全性、SQLインジェクション対策の話をしているようですよ。私も都度コンパイルの性能に不満はないので、パラメタ機能が使いたいだけだと明言していますし。

ukさんの書き込み (2005-07-07 19:51) より:

パラメータクエリだと、SQL文が固定でなければならない、と思っていませんか?
パラメータクエリ自体を組み立てればいいんですよ。

こばさんさんの書き込み (2005-07-07 20:05) より:
　ただそうなると、プログラム側でパラメータクエリを使用した SQL文 をその都度生成するということですよね？
　直に SQL 文書いたほうがラクチンという話になってしまう訳でして・・・

　それも、SQL インジェクション を防止するということが目的であれば、致し方なしと考えるべきか。。
　ひとまず、今までの投稿では、「'」→「''」（シングル2つ）に変換して使えば、少なくとも SQL Server では インジェクション されることはなかろうという風な話になってますが、どうなんでしょう。

　ひとまず、今までの投稿では、「'」→「''」（シングル2つ）に変換して使えば、少なくとも SQL Server では インジェクション されることはなかろうという風な話になってますが、どうなんでしょう。