初心者歓迎！ネットワークセキュリティ入門 第3回

ネットワークの脅威と対策を一から学ぼう

拡がるWebの脅威と対策を理解しよう

アプリケーション側でのセキュアコーディング

　Webアプリケーションの脆弱性を減らすためには、セキュリティを意識したアプリケーション開発「セキュアコーディング」^※7が必要となる。

※7：セキュアコーディング　セキュアコーディングの手法を学ぶには、IPA（情報処理推進機構セキュリティセンター）で公開されている「安全なウェブサイトの作り方　改訂第3版」をお勧めしたい。

　ここではSQLインジェクション対策として、ユーザーが入力した文字列から、特別な意味を持つ文字やコードを取り除くようにするという例を見ていこう。図9はパスワードを変更するためのSQLの例である。しかし、ユーザー入力値をチェックせずにそのままSQL文の組み立てに使用してしまうと、任意のSQL文を混入され実行されてしまう恐れがある。

図9　パスワード変更のSQLの例

　たとえば、これに対して「 $ ./userpwd abc "def' or USER='admin" ghi」を実行された出力結果は

「UPDATE USER_ACL SET 
PASSWORD= 'ghi' WHERE USER= 'abc' and PASSWORD= 
'def' or USER= 'admin'」

になる。つまり、「USERがabcでPASSWORDがdefであるレコード」および「USERがadminであるレコード」をUPDATEの対象としてしまい、｢abc｣だけでなく「admin」ユーザーのパスワードが分からなくても、「admin」ユーザーのパスワードを「ghi」に変更できてしまうという問題が発生してしまう。SQL文の文字列定数では、「'」「￥」「；」などの文字が特別な意味を持つ。そして、実行例ではこのうち「'」を悪用しているのだ。

　外部から任意のSQL文を不正に混入されないためには入力値を徹底的にチェックする「サニタイジング（無害化）」処理が必要である。上記SQL例でいえば、8行目に以下のようなコマンドを挿入する。

$msg =~ s/'/''/g; # ←「'」を「''」に置換 
$msg =~ s/??/????/g; # ←「?」を「??」に置換
$msg =~ s/;/??;/g; # ←「?」を「?;」に置換 
$statement = "INSERT INTO MSG_TABLE VALUES ( '$msg' )";

　こうした入力値のチェックの他、アクセス権設定の強化や推測困難なセッションIDの設定、さらにはユーザー認証の強化、Cokkieの保護など、各攻撃に対して、さまざまなコーディングが必要になってくる。

専用のセキュリティ装置で攻撃を防ぐ

　Webアプリケーションのセキュリティを確保するためには、こうしたセキュアコーディングをきちんと実施するのが前提である。しかし、すでにサービスを開始しているアプリケーションを一度停止して再度改良を加えるのは実際には難しい。また、当初からの開発計画に入っていない場合は、あとから追加でコストが発生する場合もある。こうした場合は、Webアプリケーションを稼働させたまま、セキュリティ装置で攻撃を遮断するという方法を採ることになる。

　たとえば、前回紹介したネットワーク型のIDS/IPSでも監視・防御が行なえる。シグネチャに不正なコマンド等を登録しておき、こうしたコマンドを含む通信を遮断するわけだ。

　さらに最近では、Webアプリケーションの防御を専門で行なう「WAF（Web Application Firewall）」という製品も登場している。

写真1　インパーバのWAF「SecureSphre」

　第1回で述べた通り、ファイアウォールの種類には、パケットフィルタリングタイプとアプリケーションゲートウェイがある。前者はおもにIPアドレスとポート番号の組み合わせでルール（破棄または許可）を設定し、入ってきたパケットのIPアドレスとポート番号の組み合わせでルールに従った動作を行なう。後者は、事前にパケットの内容でルールを設定し、ファイアウォールに入ってきたパケットの内容と照合してルールどおりの動作を行なう。

　Web Application Firewallは、後者のアプリケーションゲートウェイのHTTPバージョンといえる。HTTPのデータの内容を見て、不正なアクセスと判断した場合、そのリクエストまたはレスポンスを拒否する。

WAFのセキュリティモデル

　WAFはIDS・IPSやファイアウォールのように「不正な通信を遮断する」というポリシーだけではなく、「正当な通信のみ通過させる」^※8というモデルも採用する。これを実現するため、WAFではWebページのフォーム等で管理者が想定している正常な通信をあらかじめ定義付けておく（図8）。入力されるURLやHTTPパラメータ、Cookie、クエリ、コマンドなどを決めておき、想定外の文字列が入力された場合は、通信を遮断したり、エラーを表示するのだ。もちろん、Webページごとにこうした設定を行なうのはきわめて負荷が大きい。そのため、通常はWAFにトラフィックを監視して、標準的なパラメータを学習させ、それらを調整するというチューニングを施す。

*****[image]zu_08.png*****

※8：正当な通信のみ通過させる　不正な通信を定義し、検出したら遮断するというポリシーを「ネガティブモデル」、正当な通信を定義し、それ以外を遮断するというポリシーを「ポジティブモデル」と呼ぶ。

　こうしたWAFのフィルタリング技術により、これまでみてきたバッファオーバーフローやディレクトリトラバーサル、SQLインジェクション、クロスサイトスクリプティングなどの攻撃からWebサーバおよびWebアプリケーションを守ることができる。

　ただし、SSL通信で暗号化された通信内容は、チェックすることができない。また、複雑な処理をソフトウェアで高速に行なう必要があるため、製品も概して高価だ。

-->