アカウント名:
パスワード:
例えばOracleDBMSなんかだと, 一回構文解析したSQLはキャッシュ上に保存しておいて, 同じ字面のSQLが再発行された場合にはキャッシュ上の解析済みのコードを実行するようになっています. この効果は抜群で, 1回目には100m秒単位でかかっていた解析処理が2回目以降は10m秒未満から1m秒単位で実行可能になり, それに応じてCPU負荷も減ります.
そのため, OracleDBMSを利用したエンタープライズシステムではSQLの動的生成は論外に近く, 基本的にPreparedStatementを使ってパラメータのみを変更するのが定石になっています. 副次的に, PreparedStatementを使うと, かなりの割合のSQLインジェクションを防ぐことができるという利点もあります.
そういった開発パターンに慣れている立場から見ると, それほど容易にSQLインジェクションを可能にする環境というのがどういうものなのか, 逆に興味があります.
# 因みにOracle9iのJDBCだとバインド変数でVARCHAR2(4000)にShiftJISの2byte文字を2000文字入力できなかったりします。
それはおそらくDBの設計, さらに遡れば業務分析やシステム構成設計がまずいと思います. 平たく言えば, 使い方が悪いってやつですね. だって, バインド変数で渡さなければならないものって通常はキーパラメータですから, 普通に考えればそんなに長大なキー項目はハッシュやB+木といった一般的な検索方法では効率が悪いし, インデックスキャッシュの使用効率も悪くなって性能がた落ちっていうのが見えますから.
ただ, 上流からそういう設計でやれと言われたらやらなくちゃいけない立場も分かるし, そういうダメ設計になった理由もあらかた想像がついちゃうんですけどね.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
SQLは人が手で入力して使うツール (スコア:1)
コードにSQLの断片を埋め込んで、パラメータを文字列連結して、ランタイムでコードがSQLを生成するのは、全面的にやめるべきだと思います。
メンテナンス性の為や手抜きのために複雑な構文解析機を通して検索ロジックを実行時に機械語へビルドしている事になるわけですが、安全なサービスの構築のためにはロジックは静的に用意されているべきだと思います。
上に ORM をのっけて蓋をするのでもいいんですが、SQLという文字列でロジックをDBSに渡すというのは、無駄が多すぎる気がしてなりません。
良い解決策をもっているわけではないのですが…
Re: (スコア:4, 興味深い)
例えばOracleDBMSなんかだと, 一回構文解析したSQLはキャッシュ上に保存しておいて, 同じ字面のSQLが再発行された場合にはキャッシュ上の解析済みのコードを実行するようになっています. この効果は抜群で, 1回目には100m秒単位でかかっていた解析処理が2回目以降は10m秒未満から1m秒単位で実行可能になり, それに応じてCPU負荷も減ります.
そのため, OracleDBMSを利用したエンタープライズシステムではSQLの動的生成は論外に近く, 基本的にPreparedStatementを使ってパラメータのみを変更するのが定石になっています. 副次的に, PreparedStatementを使うと, かなりの割合のSQLインジェクションを防ぐことができるという利点もあります.
そういった開発パターンに慣れている立場から見ると, それほど容易にSQLインジェクションを可能にする環境というのがどういうものなのか, 逆に興味があります.
Re: (スコア:1, 興味深い)
PostgreSQLだろうがMySQLだろうがSQLServerだろうがACCESSだろうが一緒です。
# でも、その例だとPreparedStatementにつっこむSQLは動的生成してんじゃないの?
# 組み立ててなくともアドホックなクエリなんだから扱いは一緒だと思うぞ。
# 静的というならストアドなりDBMS側に持たさないと。
ところでさ、昔ながらのクラサバ構成でも入力された値をそのままSQL文に繋げて実行するなんてことはしなかったよね。
「SQLインジェクション」なる言葉ってWebアプリが流行ってから出てきただと思うのだが違う?
それ
Re:SQLは人が手で入力して使うツール (スコア:1)
それはおそらくDBの設計, さらに遡れば業務分析やシステム構成設計がまずいと思います. 平たく言えば, 使い方が悪いってやつですね. だって, バインド変数で渡さなければならないものって通常はキーパラメータですから, 普通に考えればそんなに長大なキー項目はハッシュやB+木といった一般的な検索方法では効率が悪いし, インデックスキャッシュの使用効率も悪くなって性能がた落ちっていうのが見えますから.
ただ, 上流からそういう設計でやれと言われたらやらなくちゃいけない立場も分かるし, そういうダメ設計になった理由もあらかた想像がついちゃうんですけどね.
Re: (スコア:0)
繰り返す場合、単純に構文解析のオーバーヘッドが削れて速くなると思ってるんですが。