EmotionTechテックブログ

株式会社エモーションテックのProduct Teamのメンバーが、日々の取り組みや技術的なことを発信していくブログです。

脆弱性診断の動的スキャンを実施してみた

はじめに

こんにちは、QAエンジニアのもときです。 エモテクにjoinして、まもなく1年になろうとしています。 今回はこの1年で活動してきたことの中から脆弱性診断について、お伝えしたいと思います。 この記事は エモーションテック Advent Calendar 2023 の12日目の記事です。

過去に取り上げた脆弱性診断

脆弱性診断は、以前別の記事(https://tech.emotion-tech.co.jp/entry/2022/04/26/165408)でも取り上げました。その当時は、OWASP ZAPの自動スキャンを実施した際の手順や結果などをお伝えしました。今回は、OWASP ZAPの動的スキャンを実施した雑記などを書き綴ってみようと思います。

なぜ脆弱性診断を実施するのか?

ご存じの方も多いと思いますが、なぜ脆弱性診断を実施するのでしょうか?かか 我々QAエンジニア/テスターは、日々実施しているテストでバグを検出しています。バグの中で、データ流出など悪用可能なバグを「脆弱性」と呼びます。この脆弱性を利用して、様々なセキュリティインシデントが世界中で発生しています。これらのインシデントの発生は企業の社会的信用の失墜に繋がり、会社の経営にも悪影響を及ぼします。このような事態を防止するため、インシデントを未然に検出、修正するため、脆弱性診断を実施しています。

正常系のテストや異常系のテストを実施して、脆弱性を検出することも可能ですが、テストパターンはキリがありません。「テストの7原則」にもあるように全数テストは不可能です。そこで脆弱性診断ツールを活用します。脆弱性診断ツールを使用することで、手動テストよりも多くのテストパターンを実行することが可能です。そこで弊社ではOWASP ZAPを使用して、脆弱性診断を実施しています。

なぜ動的スキャンを実施したのか?

以前、記事で取り上げたのは、自動スキャン実施時のエピソードでした。今回、改めて脆弱性診断を実施するにあたり、OWASP ZAPのスキャンタイプについて、調べてみました。OWASP ZAPのスキャンタイプは、大きく分けて3タイプあり、ポイントを纏めると以下のようになります。

  • 自動スキャン
    • URLを指定し、検出されたページに対してスキャンを実施します。
      →診断の強度は弱く、これだけで「問題なしです」とは言いがたいです。
  • 静的スキャン
    • ユーザーが操作(アクセス/リクエスト)した時のレスポンスを元に診断を実施します。
  • 動的スキャン
    • 静的スキャンの時のリクエストを元に自動でリクエスト内容を変更、生成してくれます。これで色々なパターンのリクエストをこれで色々なテストパターンのスキャンが自動で実施され、自動スキャン/静的スキャンよりも強度のあるスキャンが実施できます。

上記に挙げているように、自動スキャン、静的スキャンよりも動的スキャンの方が強度が強く、多くのテストパターンを実施してくれます。そこで動的スキャンが脆弱性の検出には向いているという判断の下、動的スキャンを実施しました。

実施手順

以下の手順で実施しました。

  1. 診断用の環境の用意
  2. テスト対象を選定 → 診断対象のURLを選定
  3. 静的スキャンを実施
  4. 動的スキャンを実施

まずは静的スキャンを実施

診断用環境に対して、まずは静的スキャンを実施しました。 診断環境にアクセスした時の履歴がステータスコード:200になっていることが確認できます。以下の画像のように、OWASP ZAP内の履歴タブからアクセス履歴が確認できます。

履歴画面
また、アラートタブにもスキャンで検出された脆弱性が表示され、スキャンされていることも確認できました。
アラート (静的スキャン)

いざ動的スキャンを実施

静的スキャンも無事完了したので、動的スキャンを実行しました。 「これで実施完了まで別の作業をするか」と思っていたら、ものの数分で動的スキャンが完了しました。実施結果を見たら、リクエスト数が軒並み0件でした……。履歴タブを確認してもステータスコードが400系ばかりで、アクセスできていないことが確認できます。

Not Found
診断内容を精査したところ、動的スキャンの対象にログイン処理が必要なURLを含めていて、不特定の文字列で何度もログイン試行をした結果、アカウントロックがかかってしまい、診断できず、リクエスト数が0件になっていました。

気を取り直して再実施

ログイン処理が必要なURLは今回は診断対象外にして、再実行したところ、リクエスト数は時間を経るにつれ増加して、ステータスコードも200になっており、期待通りに診断が行われました。

実施してみた結果

数時間後、動的スキャンは完了しました。 動的スキャン実施後、アラートタブを見ると静的スキャン実施時よりも多くのアラートが表示されていました。

アラート (動的スキャン)

今後の課題

OWASP ZAPの動的スキャンを実施することで、今後の課題が見えてきました。

  • アラートに挙がってきた指摘の対応方法の検討
    • アラートに挙がってきた指摘をいつまでに修正するかを検討する必要があります。また、中には過剰検出しているアラートもあるので、アラートの内容を細かく精査して、対応内容を決める必要があります。
  • 診断対象外に対して再度動的スキャンの実施
    • 今回は診断対象外にした箇所がいくつかありましたが、こちらについて再度動的スキャンを実施し、脆弱性の有無を確認する必要があります。

おわりに

簡単ではありますが、OWASP ZAPの動的スキャンを実施した際の失敗談、雑記を書いてみました。これからOWASP ZAPを使用して動的スキャンを実施しようとしている人の参考になれば幸いです。