OWASP ZAP でペネトレーションテストを学ぶ（前編）
これは何？
前職では、アプリケーションセキュリティテスト(AST)ツールの販売に関わっていて、SASTやSCAは詳しくなったが、DASTに関してはツールはもちろんテスト自体の知見もあまり身につけられていなかった。
そんな中、現職の年間目標の一つにDASTを取り入れることを挙げていたのと、開発中のWebアプリケーションの脆弱性診断を委託することになり、ペネトレーションテストを学びたいモチベーションが出てきたので、夏休みの宿題としてOWASP ZAPの使いながらベネトレーションテストの基本を学ぶことにした。
前編では座学としてZAPを使う前にペネトレーションテストについてOWASP ZAPの公式マニュアルを中心に学んだことを整理する。
後編では実際にZAPを使ったペネトレーションテストを実行して理解したことをまとめる。
なお、本来の目標は「ZAPによるペネトレーションテストをCI/CDパイプラインに組み込んで自動プロセス化する」だったが、予定通り進まなかったので、宿題事項は引き続き検証を進める予定。
ペネトレーションテストとは
悪意ある攻撃者のように振る舞ってシステムに侵入し、データを盗んだりサービスが正常に動作出来なくなるような攻撃を目的として実施するテストのこと
目的
脆弱性を探し出しその脆弱性に対処できるようにすること。また、特定の攻撃に対してシステムが脆弱でないことを検証したり、検出した脆弱性を修正して再検証すること。
メリット
動作しているシステムに対して実際にテストして脆弱性を検出するため、誤検知(存在しない脆弱性が報告されるなど)が少なく正確な結果が得られる。 他にも、防御の仕組みの検証、対応策の検証、セキュリティポリシーの遵守の確認などにも利用される。
その反面、検証用環境を構築し必要なデータを投入するなどの準備を行なったり、実際にシステムとの通信を行って検証するので、テストの実施に時間が掛かる。
ペネトレーションテストの基本手順
- 探索する(Explore): テスト対象のシステムを調べる
- システムが持つ全ての機能やエンドポイントを特定する
- パッチはインストールされているかなどシステムの情報を調べる
- システムに隠されているコンテンツや既知の脆弱性、弱点の兆候などを探索する
- 攻撃する(Attack): 探索した情報を元に脆弱性を検査する
- 報告する(Report): 検査結果を報告する
ペネトレーションテストで意識すること
- アプリケーションが提供する全ての機能を検査する
- 機能を利用するための全てのURLやエンドポイントをリストアップする
- 全ての機能にアクセスするための最低限のユーザー情報やデータを予め登録する
- 認証や外部のWAFに守られている機能も検査する
- 悪意あるユーザーが認証を突破したら？
- 一般ユーザーを装ってサービスが利用していたら？
- 公開していなくても機能やエンドポイントが存在するなら攻撃対象になり得る
- 未知の脆弱性の検出は難しい
- ペネトレーションテストは既知の脆弱性に対する攻撃をシミュレートする
- ペネトレーションテスト以外のセキュリティテストも併用することで脆弱性を減らす
- 自動テストと手動テストを使い分ける
- 自動テストは基本的な脆弱性検査を回帰的に検査し
- 手動テストは操作が複雑など自動では対応できないテストに集中する
- クライアントサイドで処理が完結するSPAだとZAPのようなサーバーとの通信内容を検証するツールでは検知できない。
OWASP ZAP とは
OWASP について
Open Web Application Security Project(OWASP) は、ソフトウェアのセキュリティ改善を目的とした非営利な団体
OWASPでは、ソフトウェアのセキュリティに関する様々なプロジェクトが存在する。中でも OWASP Top Ten はリスクの高い脆弱性や攻撃されることが多い脆弱性などを統計・分析した結果を公開したものでソフトウェア開発において手始めに対処するべき脆弱性を理解することに役立っている。
OWASP ZAP の主な特徴や機能
OWASP ZAP (Zed Attack Proxy) は OWASPのフラッグシップ・プロジェクトの一つで、オープンソースで公開されており、無料で利用することができるWebアプリケーション向けの脆弱性スキャナである。
- 中間プロキシとして動作する
- Spider
- Passive Scan (受動的スキャン)
- Active Scan (能動的スキャン)
- ユーザー管理と認証管理およびセッション管理
- テスト実行に必要な認証情報やセッション情報の方式を設定したり管理が行える
- テストを実行するユーザーも選択できる。ユーザーは複数管理が行え、ユーザーごとに認証情報が設定できる。
- アプリケーションにユーザーロールがある場合など、全ロールのユーザーを作成することで全ての機能とエンドポイントがカバーできる。
- アドオン
OWASP ZAP で検出できる脆弱性
- 既知の脆弱性は 脆弱性ごとにScan Rule として定義され公開されている。
- ZAPのデフォルトで検査できるScan Rule はステータスが Releaseとなっているもの。
- その他のステータスには、Alpha, Beta があり、別途アドオンで追加すれば検査が可能になる。
- 独自ルールをScriptで作成して脆弱性を検査することもできる
OWASP ZAPをインストールし、ペネトレーションテストを行う
インストール
- インストーラは下記からダウンロードできる
- Windows版とLinux版は別途、Java 8(JRE 8) 以上をインストールする必要がある
- Mac版はJava 11がバンドルされている
- Docker版もある。基本はCLI設定になるが、ブラウザから操作できるGUIも提供されている模様。(動作未確認です。)
今回の検証では、MacのHomebrew caskを使ってインストールした Version 2.1.1 を利用した
検証に利用するWebアプリ
今回は同じくOWASPのフラッグシップ・プロジェクトである Juice Shop をローカルのDockerで起動し利用した。
Juice Shopはアプリに含まれている脆弱性を攻撃することでソフトウェアのセキュリティを学ぶことができる体験型のWebアプリケーションである。
Juice Shop以外にも同様のWebアプリケーションは VWADとして公開されており、プログラミング言語やフレームワーク、実行環境に対応している。
基本の操作手順
前述のペネトレーションテストの基本手順をZAPで行う。 これは下記のマニュアルを参考にしており、実際に実施したことは 後編にまとめる。
Explorer - 探索する
- Webアプリが提供する全ての機能とエンドポイントURLを探索する。
- ブラウザで実際に全てのリンクやボタンを押したり、全てのフォームを埋めてsubmitすることで、アプリケーションとの通信（リクエストとレスポンス）をキャプチャする
Contextへの登録
- 探索したSite(URL)からテスト対象とするエンドポイントをContextに追加する。
- Contextに追加したサイトは、テストスコープの対象となり、認証情報を指定したユーザーでテストが実施できたり、セッション管理が行えるようになる。
Spider でさらに探索する
- Spiderを利用することで手動では探索できなかったり隠れていたURLを探索する
- 先に手動で探索したサイトをContextに設定しておくことで、ContextベースでSpiderを実行することができるので、認証情報を使ったり、探索が必要なサイトだけを対象にすることができる。
- 手動探索とTraditional Spiderの探索結果は重複するURLも多いので先に認証処理に関するエンドポイントを中心に手動探索してContext管理を行い、Traditional Spiderを使うと効率的かもしれない。
- Ajax Spiderも実行することで動的に生成されるリンクも探索する。
- Ajax Spiderの実行にはブラウザが必要になる。
Forced Browse - 強制ブラウズ
- 参照されていないファイルやディレクトリを発見するための探索機能。 “Forced Browse“アドオンのインストールが必要
- 一般的にURLディレクトリ（パス）の名称として使われるキーワードリストを用意して、URLを生成して探索を行うことで、元に該当するURLが無いか探索する。
- 存在するディレクトリ名を発見したら更に再帰的にパスを生成して探索する。このため探索に時間もシステムへの負荷も掛かる。
- デフォルトでは、'directory-list-1.0.txt' ファイルがインストールされている。
- 他のディレクトリリストもマーケットプレイスに公開されていたり、独自に用意してインポートすることもできる。
Passive Scan の実施
- ここまでの手動探索やSpider探索などで、探索と同時にScanを実施していた。
- つまり、Passive Scanは明示的に独立して実行する必要がない。
Active Scan の実施
- 探索したサイトに対して基本的な脆弱性を特定する検査を実施する。
- 実際のシステムに攻撃を仕掛けるので、スコープ対象以外のサイトURLへ攻撃しないように、スコープ指定を行い、Protectモードで実行することがお勧め。
- エンドポイントの数が少なくても全てを完了するまでに5−6時間掛かった。実際のアプリへのテストなら並列実行などを検討した方が良さそう。
レポートを作成する
- 検査結果をファイルに出力することができる。
- ファイル出力しなくても、ZAPのセッションを保存すれば ZAPからも確認できる。
手動テスト
Active Scanによる自動テストでは発見できない脆弱性を検証するために、手動テストを実行する。
詳細は WSTG (Web Security Testing Guide)を参照
公式ドキュメントでは、将来的にZAPが手動テストをどのように支援できるかを紹介する予定があるそうだが現時点では非公開。
例えば、探索したリクエスト/レスポンスにBreakpointを打ち、通信内容を書き換えてテストする操作なども手動テストの一種だと考える。
今回はZAPを使ってペネトレーションテストを自動実行することが目的でもあるため省略する。
前編はここまで。
実際にZAP DesktopUI から Juice Shopへのペネトレーションテストを実施した結果は、後編にまとめる。
追記：
Active Scanで、Cross Site Scripting (DOM Based) の検査が行われるようになっていて、SPAこれならクライアントサイドで発生するXSSの検証ができるのかもしれない。
ただこのルールはまだ Beta版で、下記の説明の通り ヘッドレスモードのブラウザで検証しているせいか、他のルールと比較して圧倒的に時間を消費している*1ので、現時点で有効なルールではない気がする。
