佐々木です。

> いちいち個別に対応する必要は無い

その通りですね。
抽象的な物言いになりますが、個人的には
システムの構成要素全てに対して個別のリスクを考慮するのは大変ですから、
基本的には何を表（管理できない範囲）に晒すかを定め、如何にその範囲を小さくするかが重要だと考えています。

バッファオーバーフロー等のソフトウェア自身に属する脆弱性を除けば、
サービスを提供するソフトウェアが利用するDBユーザに与えられる権限
＝ SQL Injection で不正操作が可能な範囲といえるでしょう。
ですから、データベース設計とプログラム設計を工夫して、
ユーザインターフェイス処理には指定のデータベースに対する
SELECT と INSERT 以外の権限を与えないようにすれば、SQL Injection が
原因でトラブルが発生する可能性はかなり低くなると思います。

その上で、表に晒した部分（HTTP プロトコル等）が原因で
どのような事態が発生し得るかを予測し、絶えず通信状況を記録できる
環境を整えておきます。
これについて IDS や NIDS の利用はある程度有効なんですが、
現実に存在するソフトウェアだと完璧なチェッカーとしての役割は
果たしてくれそうにありません。
（威嚇効果はありますけど）

なので、一番重要なのはトラブルが発生する範囲と影響度を把握しておく
こと、トラブルが発生したときに原因究明が出来る情報を事前に収集できる
体制をつくること、この両者だと思われます・・・。

上記を与えられたコストに見合う方法で如何に構築するかですね。
複雑にするとセキュリティ以前に機器障害やソフトウェアの不具合で
トラブルが発生しますから。:-)

例えば MySQL なら一般クエリログやバイナリログを有効にしておけば
SQL Injection が原因で発生したトラブルの原因究明に役立つのでは？


"Kiyotaka Doumae" <don@xxxxxxxxxx> wrote:
> 堂前です
> 
> pix@xxxxxxxxxx wrote:
> > パラメータのチェックを厳密にし、不要な権限は割り当てない。というのがSQL
> > インジェクション攻撃に対する基本的な対策だと思いますが。保険としてさらに
> > 取れる事は無いのでしょうか。パラメータのチェックについても新しい手法が
> > 見つかる度に対応するのは保守が大変です。アンチウィルスソフトやＩＤＳで
> > SQLインジェクション攻撃自体を検出・防御することは可能なのでしょうか。
> 
> パラメータのチェックについては、特定の異常な文字列を検出するのではなく
> て、「正しく無い文字列は受け付けない」「副作用を起こす可能性がある文字列
> はエスケープする」というようにすれば、いちいち個別に対応する必要は無い、
> はずです。
> 
> ちなみにこの手の問題に対して AntiVirus や IDS は無力です。
> # full capture する IDS ならあとから記録を参照できたり、あるいは特定の攻
> 撃に対する signature を持っていれば、それに限定してなら対応できるかもし
> れませんが。
> 
> 世間には、この手の問題に対して「Webアプリケーション ファイアウォール」な
> どというカテゴリの製品が存在します。
> 各メーカー・ベンダからいろいろ出ていると思いますので、気になるようでした
> ら懇意にされている販社にでも相談されてはいかがでしょうか。
> # まあ、いろいろありますから
> 
> -- 
> DON (堂前清隆)
> don@xxxxxxxxxx / http://www.don.am/~don/
> 
>