第14回 Webアプリケーションセキュリティの常識：知ってるつもり？「セキュリティの常識」を再確認（4/4 ページ）

[杉山俊春（三井物産セキュアディレクション），ITmedia]

　手動では自動検査ツールではできない検査もすべて行うことができるが、当然ながら非常に時間がかかってしまう。しかし、検査の正確性を重要視する場合は手動による検査を行い、安全性を確実にするべきである。

手動検査の補助ツール

　手動での検査といってもブラウザだけでできる範囲ではとても限られてしまっている。そこで、パラメータを操作するための検査補助ツールを利用する。

　パラメータを操作するための検査補助ツールは、MITM（Man In The Middle）攻撃のように振る舞い、途中でデータを書き換えることができる。クライアントPC内でプロキシサーバとして動作し、ブラウザのプロキシ設定を「lodalhost:ポート番号」のように設定することで、すべてのhttp通信がこれらのツールを経由する形となる。https通信も通信を両側で終端することによって書き換えが可能である。このようにして、ブラウザから送信されるデータのうち脆弱性のありそうなパラメータを検査パターンに書き換えることによって検査を行う。

検査補助ツールを介してサーバとHTTP通信を行う

　これらの手動検査の補助ツールとして、フリーで入手できるアプリケーションには以下のようなものがある。

• Achilles
• Paros
• Odysseus

　筆者が手動検査を行う際にはAchillesをよく使う。Achillesは設定が簡単で、通信内容を簡単に編集することができるからだ。

HTTP通信を閲覧でき、直接書き換えることができる。（Achillesの例）

手動による検査のポイント

　では、具体的にどのような観点で検査を行えばよいのだろうか？データを書き換えると簡単に書いたが、Webアプリケーションの規模が大きい場合、すべてのページのすべてのパラメータに対して、全部の検査パターンを試すのには膨大な時間がかかる。その上、実際には対象となるページの機能によって、試す意味がないパターンも多い。

　そこで、あらかじめページ巡回しておいて全体を把握する。どこでどういった処理がなされているかに注目しておき、検査パターンと対象個所を絞っておく。例えば、

• データベース（DB）にアクセスしていそうな個所
• ブラウザから渡される値をそのまま表示する個所

といった部分に注目して巡回を行う。

　例えば、ログインやユーザー情報照会などのDBにアクセスしていそうな個所には、SQLインジェクションの危険性が潜んでいる場合が多く、ブラウザから渡される値をそのまま表示する個所にはクロスサイトスクリプティングの危険性が潜んでいる場合が多い。どのパラメータにどのような検査パターンを適用すればいいかの判断は経験が必要となるが、脆弱性が潜んでいそうな個所を把握できるようになれば、格段に検査効率と精度が向上する。

　また、自動ツールで行えない検査として、

• セッション管理を行っている個所
• そのほか重要な処理を行っている個所（登録情報変更や購入処理など）

に関する検査が挙げられる。これらの個所では、セッション管理に利用されているセッションIDの推測が容易でログイン回避を行えたり、正当な利用者が第三者のいたずらによって意図しない商品を購入させられてしまったり（クロスサイトリクエストフォージェリ）といったことが発生しうる。

　これらは、対象Webアプリケーションの全体の構成や各ページ、パラメータの機能とその意味を把握していないと検査が難しい。これらの項目は一見正常動作をしているように見えてしまうため、自動検査ツールなどでは難しく、人手を介さないと検査が行えない場合が多い。

　以上、検査手法や検査ツールなどを簡単に紹介した。ソースコードの検査、外部からのツールおよび手動による侵入検査のすべてを行うことが理想ではあるが、多大なコストがかかってしまう。そのため、Webアプリケーションの開発を行う際は、Webアプリケーションの規模や用途、各Webアプリケーション内の処理の重要性に応じて、どのように検査手法を組み合わせ行っていくかの判断が重要な鍵となる。