ブラックボックステストの基本

ブラックボックステストとは

高品質で安全なアプリケーションを開発することは、ソフトウェア開発における最大の課題の一つです。セキュリティテストは、ソフトウェアに潜む潜在的な欠陥やセキュリティ上の弱点を特定し、この両方の実現を支援します。ブラックボックステストは、攻撃者がシステムの欠陥を悪用してアクセスを得る方法をシミュレーションするため、取り組みの出発点として適しています。

この記事では、テストの種類や手法など、ブラックボックステストについて知っておくべきことをすべて解説します。

ブラックボックステストの図

ブラックボックステストの4つの種類

セキュリティ担当者は、システムのセキュリティを評価するために、自動と手動の両方を含むさまざまなブラックボックステスト手法を活用します。代表的なブラックボックステストの種類をいくつか見ていきましょう。

1. 脆弱性スキャン

アプリケーションをハッキングするには、攻撃者はまずその仕組みを理解する必要があります。脆弱性スキャンは、ハッカーがシステムについて学び、セキュリティ上の弱点を見つける簡単な方法です。一方で、脆弱性スキャンはアプリケーションセキュリティにおいても重要です。攻撃を防ぐために、ハッカーの立場でシステムを調べられるからです。

ZAPのような自動ブラックボックステストツールでは、比較的見つけやすい脆弱性が検出されることがよくあります。経験豊富なセキュリティ担当者は、手動での脆弱性テストを組み合わせることで、自動テストで見逃す可能性のある脆弱性も発見できます。また、Kali Linuxでサポートされているツールや、Webアプリケーションの検査に使うChrome DevToolsなど、複数のツールを併用して脆弱性を確認することもできます。

2. ペネトレーションテスト

ペネトレーションテストでは、ハッカーがデータへのアクセスや収集を試み、システムを侵害する悪意ある行為を行うという、現実の攻撃シナリオをシミュレーションします。

ペネトレーションテストは通常、テスターの経験に基づいて手動で実施されます。たとえば、ユーザーが購入できる商品の一覧を取得するAPIを検査できます。この場合、さまざまな入力値でテストし、異常な応答やスタックトレースのエラーが表示されないかを確認します。

Powershell Suiteなどのオープンソースツールを使って、ペネトレーションテストを自動化することもできます。

3. ネットワークトポロジーの把握

ネットワークトポロジーを把握すると、システム内の現在のネットワーク構成や、ネットワーク上の要素同士の接続関係、相互のやり取りを理解できます。これにより、ネットワークシステム内の潜在的に脆弱な要素を特定し、リスクを軽減できます。

4. リスク評価

この独自のセキュリティテストでは、システムに関する技術的な知識はほとんど必要ありません。むしろ、セキュリティリスクにつながりうる要件など、ビジネス面に重点を置きます。リスク評価は、ソフトウェア開発チームの構想段階やスプリント計画など、製品開発のごく初期から実施できます。そのため、SDLCの早い段階でセキュリティ上の問題を防ぐことができます。

ブラックボックステストの例

ブラックボックステストの例を見てみましょう。

まず、このリポジトリをローカル環境にクローンします: https://github.com/appsecco/dvna。これにより、悪用可能な欠陥がいくつか含まれたサンプルアプリケーションが起動します。

次のコマンドを実行すると、すぐにサンプルをセットアップできます。

docker run --name dvna -p 9090:9090 -d appsecco/dvna:sqlite

ZAPによる自動脆弱性スキャン

ブラックボックステストにはZAPを使用するため、マシンにZAPをインストールしてください。

まず、サイトの脆弱性を確認するために自動スキャンを実行します。スキャンが完了すると、脆弱性に関するアラートの一覧と、それぞれの説明および推奨される修正方法が表示されます。

手動によるSQLインジェクション

自動スキャンは簡単に実施でき、セキュリティテストの出発点として適していますが、手動でのテストが必要なセキュリティ上の側面もあります。SQLインジェクションはその一例です。アプリケーション内で検索するために、単純なSQLの ' or '1'='1 を実行してみましょう。

この例では、システムの全ユーザーに表示されるユーザーインターフェースに影響が及んでいます。これにより、ハッカーがシステムユーザーのデータを収集したり、顧客データを競合他社に売却したりするおそれがあります。

ブラックボックステストのプロセス

ブラックボックステストでは、ソフトウェア製品のコードにアクセスしたり、アプリケーションの開発方法を深く理解したりすることなく、悪用される可能性のあるセキュリティ上の問題をシステム内で確認します。テスト完了後、レビュー、優先順位付け、修正が必要なセキュリティバグの一覧が提供されます。

次のステップは以下のとおりです。

• 開発チームが、それぞれのセキュリティ上の問題に対する解決策を見つけます。

• セキュリティアナリストが、バグが確実に修正されていることを再確認します。

• 開発チームが回帰テストを実施し、すべてが正常に動作し、修正によって既存の機能が壊れていないことを確認します。

ブラックボックステストの4つの手法

セキュリティテストは、特にブラックボックステストにおいて、芸術ともいえます。基本となるのは、創造力を発揮してハッカーの視点で考えることです。活用できるブラックボックステストの手法は数多くあります。

1. ファジング

ファジングでは、APIサービスやWebインターフェースにランダムまたはカスタマイズした入力を与え、システムの挙動をテストします。異常な挙動が検出された場合、開発チームは根本原因を特定し、修正策を考える必要があります。

2. 構文テスト

構文テストでは、誤った構文などの無効な入力を確認します。また、ハッカーに悪用される可能性のある、データベースや顧客情報に関する機密データがシステムに表示されないかも検査します。

3. 探索的テスト

探索的テストは、セキュリティテストの過程で隠れたセキュリティ上の問題を探し、システムへの理解を深めるためにセキュリティアナリストがよく使うブラックボックス分析手法です。テストを進めるなかでセキュリティバグを発見・報告し、修正案を提示します。

4. データ分析

データ分析テストでは、ログやAPIバックエンドサービスからの応答、Webインターフェースを確認し、違法性のあるものや、システムへの攻撃またはユーザーデータの収集に悪用されうるものがないかを調べます。データ分析テストを適切かつ効率的に実施するには、ログを収集しデータを可視化するための優れた監視・デバッグシステムが必要です。また、セキュリティ上の問題が発生した際にすぐ通知されるよう、セキュリティアラートのルールを設定する必要がある場合もあります。

ブラックボックステストとホワイトボックステストの比較

セキュリティテストでは、ブラックボックステストとホワイトボックステストの両方が必要になる場合があります。代表的なブラックボックステストとホワイトボックステストである、動的アプリケーションセキュリティテスト（DAST）と静的アプリケーションセキュリティテスト（SAST）の違いを見ていきましょう。

ブラックボックス方式: 動的アプリケーションセキュリティテスト（DAST）

• アプリケーションのソースコードにアクセスして分析せずに、動的にテストします。

• セキュリティ専門家が手動で、または自動で実施できます。

• ソフトウェアの内部構造にアクセスせず、外部からアプリケーションをテストします。

• コードベース全体を網羅できたか確認するのが困難です。

• テストのためにアプリケーションをデプロイする必要があるため、一般にコストが高くなります。

ホワイトボックス方式: 静的アプリケーションセキュリティテスト（SAST）

• SASTはソースコードの分析に使用されます。

• 通常、コードのコンパイル前に実施されます。

• 多くの場合、自動SASTツールを使用します。

• コードベース全体を100%分析できます。

• ソフトウェア開発ライフサイクルの早い段階でセキュリティ上の問題を発見できるため、修正コストを抑えられます。

ブラックボックステスト、ホワイトボックステスト、あるいはその両方のうち、どれが適しているかはユースケースによって異なります。

まとめ

ブラックボックステストは、アプリケーションセキュリティの重要な要素です。ソフトウェアの内部アーキテクチャに関する知識がなくても、このテスト手法によってアプリケーションを客観的かつ現実に即して評価できます。コードベース全体を網羅できない場合もありますが、ほかのセキュリティテスト手法と組み合わせれば、セキュリティチームが高品質でより安全な製品を提供するうえで役立ちます。

開発者ファーストのツールと業界最高水準のセキュリティインテリジェンスを提供するSnykは、コード、オープンソースライブラリ、コンテナ、Infrastructure as Codeを安全に保ちながら、開発者が高品質な製品をより速く提供できるよう支援します。今すぐデモを予約しましょう。