Webアプリケーションの脆弱性を見つけるには

Oct 17, 2016

第3回目はWebアプリケーションの脆弱性を見つけるための基本的な手法を説明します。

ここではWebの仕様やWebアプリケーションの仕組みについての説明は割愛します。Webの基礎から学びたい方は「3 Minutes Networking」で詳しく解説しているので、まずはそちらをご覧ください。また、以下の書籍も参考になります。

『プロになるためのWeb技術入門』技術評論社
『HTTPの教科書』翔泳社

Webアプリケーションへの調査

ソフトウェアのテスト手法の一つにブラックボックステストがあります。これはソフトウェアの内部構造を考慮せず、入力と出力だけに着目してバグを見つけ出す手法です。WebアプリケーションのプログラムはWebサーバー上で動作するため、リモートからソースコードは読めません。内部構造のわからないブラックボックスでの脆弱性調査では、HTTPのリクエスト（入力）とレスポンス（出力）をもとに調査するのが基本です。

図1. リモートからのブラックボックステスト

ブラックボックスでの脆弱性調査において、入力値処理の実装にひそむ脆弱性を見つけるには、大量の入力パターンを試すことが効果的です。そのため、脆弱性スキャナーのような短時間で大量のパターンを機械的に試すツールでの調査が求められます。しかし、世界中のハッカーが特定のWebアプリケーションへ同時にそのようなツールでの調査を行なった場合、サーバー側の処理に過剰な負荷がかかってしまいます。Webアプリケーションを対象としたバグ報奨金制度では、脆弱性スキャナーのようなツールの使用は禁止されています。

内部構造が分からず、脆弱性スキャナーも使えない状態での調査では、サーバー側を「想像」することが大切です。ハッカーも人間ですから、一定の時間に手動で入力できるパターンには限界があります。サーバー側の実装方法やデータ管理方法などを想像し、効果が期待できるパターンに絞って試すことで、手動でも脆弱性は充分見つけられます。

脆弱性スキャナーの盲点

Webアプリケーション開発の現場ではセキュリティへの意識が高まりつつあります。リリース前やリリース後に、運営者自ら脆弱性スキャナーでテストするケースは増えてきています。IPAも運営者による脆弱性検査を支援するため、IPAテクニカルウォッチで無償の脆弱性スキャナーやその利用方法を紹介しています。しかし、脆弱性スキャナーは全ての脆弱性を検出できません。

例えば、条件がそろわないと入力値が処理で利用されないような実装の場合、脆弱性スキャナーは得意ではありません。細かな条件設定や膨大な量の組み合わせの試行を求められるため、検出漏れの発生率は高くなります。

また、アクセス制御やアプリケーション固有の設計にひそむ脆弱性の検出は困難です。アカウントごとのアクセス権限の違いや機能の仕様を把握した上で、どのような操作が行なえると不正なのかを考え、手動で調査する必要があります。

今現在の機械には検出できない脆弱性がたくさんあります。また、普段使っているアプリケーションにもまだ発見されていない脆弱性はあります。誰も想像しなかった脆弱性をこれから見つけていきましょう。

次回はHTTPのリクエスト書き換えによる入力値操作の方法を説明します。