「イントラWebアプリケーションのセキュリティ」、大丈夫ですか？：システムインテグレーションとセキュリティ（3）（3/3 ページ）

[寺岡亮（ラック），＠IT]

2．3点に絞った対策、改修

　現状の確認ができたら、先に挙げた3つの脆弱性対策を実施していきます。

【ユーザー管理対策】

　イントラ環境で一番問題となるのはユーザー管理です。往々にして、「アプリケーションを利用しているのが本当にその当人なのか」ということが問題となります。社内では「ユーザーID・パスワードを社員同士が共有している」ことがよくあるからです。そこで重要となるのが「アクセスログ」です。アクセス元を追跡できるように、必ずアクセスログを取得・保存するようにアプリケーションを設定する必要があります。

　アクセスログの取得については、2つの方法があります。1つは「Apache」や「IIS」といったWebサーバ上での設定です。これは情報システム部門が設定している可能性もありますので、確認を行いましょう。もう1つの方法は、アプリケーション側でIPアドレス、操作時刻、操作画面、SQL文を含めたログを出力することです。いずれかの方法で必ずアクセスログが残るようにしましょう。

　また、ログの保存期間については、JPCERTコーディネーションセンター（JPCERT/CC）が公表している「高度サイバー攻撃への対処におけるログの活用と分析方法」にもあるように、3〜12カ月間程度保存しておくのが望ましいでしょう。

【SQLインジェクション対策】

　ソースコード中に文字列連結によりSQLを作成している部分がないかを確認し、可能な限り静的プレースホルダを利用するようにします。以下はASP.NETでの例です（参考リンク）。

改修前

String strSQL = "SELECT [USER], [PASS] FROM [T_USERS] WHERE [USER] = '" + txtUSER.Text + "' AND [PASS] = '" + txtPASS.Text + "' "

改修後

String strSQL = " SELECT [USER], [PASS] FROM [T_USERS] WHERE [USER] = @USER AND [PASS] = @PASS"
SqlCommand myCmd = new SqlCommand(strSQL, myConnection);
myCmd.Parameters.Add(new SqlParameter("@USER", txtUSE.Text));
myCmd.Parameters.Add(new SqlParameter("@PASS", txtPASS.Text));
⇒SqlParameterを利用してUSER、PASSに値を設定

　上記のようにソースコードの改修ができない場合は、WAF（Web Application Firewall）を導入するなどの対策を考えます。WAFはWebサーバに渡されるリクエストの内容をチェックし、不正なリクエストを検知、ブロックするものです。IISであれば「WebKnight」、Apacheであれば「mod_security」などを利用することでWAFを設定することができます。また、別途ネットワーク型WAFなどを採用する場合もあります。WAFは既存のSQLインジェクションなどの対策だけでなく、設定によっては本来意図しないリクエストなどを判断することもできるため、未知の攻撃に対する予防にもなります。

【ディレクトリトラバーサル対策】

　Webサーバとして公開しているディレクトリ配下（IISの標準の設定であれば、「C:\inetpub\wwwroot\」ディレクトリ配下）のファイルを全て確認します。また、Webアプリケーションがファイルの内容を読み込む場合、任意のファイルを読み込めるようになっていないかを確認します。例えば、本来は「C:\inetpub\wwwroot\data\」ディレクトリ配下のファイルのみを参照する想定のアプリケーションが、「C:\機密情報\」など意図しないディレクトリにアクセスし、ファイルを読み込むことなどが可能になってないか確認します（図1）。もしそのようなアプリケーションがあれば、アクセス権の設定を見直し、プログラムの改修を行います。あるいは、Webサーバにそもそも機密情報を配置しないことも考えましょう。

図1　IISのディレクトリ構成例

　ただし、公開しているディレクトリ配下の「不要だと思われるファイル」をすぐに削除はしないでください。そのファイルが既に不正に利用されていた場合、不正利用の痕跡まで削除してしまう可能性があるからです。削除を行う前には、必ずファイルのコピーをとっておくようにします。

3．改修結果の確認

　改修したWebアプリケーションに対して、セキュリティの観点からテストを行います。可能であればセキュリティの専門家に実施してもらうのがよいのですが、IPAから公開されている「ウェブ健康診断仕様」に記載されているリクエストを実際に発行したり、「OWASP ZAP」や「BurpSuite」などのWebアプリケーション検査ツールを利用してテストしてみたりするのもよいでしょう。

4．公開

　改修したアプリケーションを事前に確認したリリース手順に従って公開します。まずは、上記3点の対策に絞って、問題が解消するまで繰り返し改修を行いましょう。クロスサイトスクリプティングなど、その他の問題を解消するのは、上記3点が解消されてからにします。

　以上、今回はイントラ環境のWebアプリケーション改修時のセキュリティ上の考慮ポイントについて解説しました。次回は、ユーザー部門におけるアプリケーション開発後の管理、メンテナンス時のセキュリティ上のポイントを紹介します。

著者プロフィール

▼寺岡　亮（てらおか　りょう）

2001年から株式会社ラックで数年間セキュリティ業務に従事。

その後はシステム開発部門で、主にユーザー部門でのアプリケーション開発の運用・保守を担当。

セキュリティ関連の話題にも常にアンテナを張っている。