| このような場合に、IceWall MCRPをWebアプリケーションの前段に配置して、不正な文字列をフィルタリングするよう設定すると、アプリケーションの改修をすることなく、またパフォーマンスの劣化も引き起こすことなく、SQLインジェクション攻撃への防御を行う事ができます。
IceWall MCRPのSQLインジェクション対応機能では、SQLインジェクション対応機能用設定ファイル（injection.conf）に以下の各項目を定義します。
- 検査対象とするURL
- 送信データの種類(QUERY、POSTデータ、HTTPヘッダ、URL)
- 検査対象とする属性名
- フィルタリングする文字列（正規表現による記述が可能
これらを以下のように記述をします。
＜対象URL＞,＜送信データ種類＞,＜属性名＞＝＜フィルタリング文字列＞
設定例①
「/service1」以下のディレクトリ（MCRPがWebアプリケーションサーバのURLに変換）に送信されるQuery Stringのうち、useridという属性に含まれる、シングルクォーテーションをフィルタリングしたい場合は、以下の設定をします。
/service/,QUERY,userid='|%27
ここで、「|」は正規表現における「または」を意味し、%27はシングルクォーテーションがURLエンコードされた値となります。
この設定によって、悪意のあるユーザがシングルクォーテーションを含んだ文字列をuseridという属性に埋め込んで送信してきた場合、MCRPがエラー画面を表示します。
設定例②
先ほどの設定例①ではシングルクォーテーションをフィルタリングしましたが、アプリケーションによっては、シングルクォーテーションが入力される場合（外国人の名前等）が想定される場合があります。そうした場合は、例えばSQLで使用する予約語などをあらかじめ定義しておくことでSQLインジェクションの実行を防ぐことができます。
/SQL/,POST,=or|select|insert|update|OR|SELECT|INSERT|UPDATE
この設定では、「/SQL」以下のディレクトリに、POSTデータ内の任意の属性（設定を省略した場合はすべての属性が検査対象となります）内に、SQLで使用されるOR、SELECT、UPDATE、INSERTが含まれている場合にMCRPがエラー画面を表示します。
当然、これらの文字列がアプリケーション上で使用される可能性もありますので、その場合は設定例①と②を、正規表現を使ってうまく組み合わせる等の対応が必要になる場合もあるでしょう。
具体的な設定例③
ごく最近、新しい攻撃パターンとして、フォームの入力文字列ではなく、ユーザに発行されるCookieの情報の中にSQL文を埋め込み、データベースの改ざんなどを行う手法が出てきています。ユーザに発行したcookieを都度データベース内に保存・更新してセッション管理等を行うアプリケーションを狙った攻撃で、実際に商用サイトで被害も出ているようです。IceWall MCRPではcookieをはじめとするHTTPヘッダ内の情報に含まれる文字列もフィルタリングができます。例えば、cookie内にシングルクォーテーションが含まれていた場合、フィルタリングを行う設定は以下となります。
/web01/,HEADER,Cookie='|%27
|
