SQLインジェクション対策はおすみですか?
開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、
脆弱性発見後の適切な対策まで
トップ «前の日記(2007-06-05) 最新 次の日記(2007-07-01)» 編集
過去の日記

2007-06-14 変数に型のない言語におけるSQLインジェクション対策に対する考察(4)

SQLの「暗黙の型変換」で実行速度が遅くなるのはどのような場合か

数値リテラルをシングルクォートで囲むことの是非にて、「変数に型のない言語」(Perl、PHP、Rubyなど)で数値項目に対するSQLインジェクション対策について検討した。その際に、数値リテラルを文字列リテラルとしてシングルクォートで囲む(中の値はエスケープする)という方法を紹介した上で、文字列型から数値型への「暗黙の型変換」により、SQLの実行が遅くなる可能性を指摘した。
 この情報は、ネット上で検索すればすぐに見つかるものであるが、私自身試したことはなかった(なにせ暗黙の型変換などやりたくないクチなので)。
 しかし、実験もせずに「SQLの暗黙の型変換はパフォーマンスが劣化する」と断言するのもエンジニアとしてどうかと思い、簡単なサンプルで実験を行ってみた。
 実験には、Oracle Database 10g Express Editionを使用して、TKPROFユーティリティにより測定を行った。ただし、データ量が1万件しかないので実行速度については有意な差が出なかったので、インデックスの利用有無により間接的な判定を行った。
 結論から言えば、SQLインジェクション対策時に発生する「暗黙の型変換」については、パフォーマンスは低下しないようである。
 「暗黙の型変換」でパフォーマンスが低下する場合は確かに検証できたが、

文字列型の列と数値リテラルに対する演算

の場合であった。具体的には、以下のような場合である(DOC_IDは文字列型とする)。

SELECT * FROM HOGE WHERE DOC_ID = 123

この場合、すべてのDOC_IDを数値に変換しながらWHERE句が実行されるため、インデックスを使用することができずにパフォーマンスが低下する。
一方、DOC_NIDが整数型だとして、

SELECT * FROM HOGE WHERE DOC_NID = '123'

の場合は、まず'123'を整数型に変換してから検索実行されるので、インデックスが有効活用される。すなわち、パフォーマンス低下はない。
SQLインジェクション対策にあらわれる「暗黙の型変換」は後者のパターンであるため、SQLインジェクション対策に限って言えば、パフォーマンス低下は認められなかった。

しかしながら、このような実験を行うとともに、この問題に対する考察を深めた結果、やはり数値リテラルをシングルクォートで囲むというやり方には問題があると思う。その内容については稿をあらためて説明したい。

本日のTrackBacks(全1件) [TrackBack URL: http://tokumaru.org/d/tb.rb/20070614]

数値項目に対するSQLインジェクション対策について検討しました。数値をクォートしてエスケープする方法は副作用が多く、SQL組み立て時に数値チェックを行う方法を推奨します。

本日のリンク元
その他のリンク元
検索

SQLインジェクション対策はおすみですか?
開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、
脆弱性発見後の適切な対策まで
トップ «前の日記(2007-06-05) 最新 次の日記(2007-07-01)» 編集