はじめに
こんにちは。森井です。今回は、一診断員の視点から、Webアプリケーション診断を円滑かつ効率的に進めるための事前準備のポイントについてご紹介します。
弊社では、診断準備の第一歩として、ヒアリングシートへのご記入をお願いしています。このシートには、ご担当者様の連絡先、診断対象の概要、診断対象の環境、診断用アカウント、対象となるURLやAPIなどをご記載いただきます。
本記事では、ヒアリングシート記入後のやり取りや、実際に発生した課題・困りごとを具体例とともに取り上げながら、スムーズな診断実施に向けた事前準備の要点を解説していきます。
- 診断対象のURLやAPIを明確、正確にする
- リクエストパラメータで挙動が制御されるAPIを正確に伝える
- 対象URLへの遷移方法を正しく共有する
- アカウント数・ワンタイムURLを十分に準備する
- 診断対象環境に関する情報を正確に伝える
- スムーズなやり取りができる連絡体制を整える
- メール送信機能の挙動確認を事前に確認・共有する
- テストデータの準備と表示条件を明確にする
1. 診断対象のURLやAPIを明確、正確にする
体感として最も頻繁に発生するのは、「診断対象が明確でないこと」に関するやり取りです。 例えば、ヒアリングシートに記載された対象URLやAPIが、実際にはアクセスできない管理画面のURLや内部APIであることがあります。(※調整の結果、アクセスを許可していただき診断対象とすることもあります。)
ヒアリングシートに記載された診断対象については、提供された資料だけではアクセス可否を正確に判断できないことが多く、実際に対象へアクセスを試みる見積もり時や疎通確認時になって初めて問題に気づくケースもよくあります。
診断を正確かつ効率的に実施するためには、診断対象となるURLやAPIを明確にご記載いただくことが重要です。不明確なままでは診断範囲の特定や準備が困難となり、作業の遅延や診断漏れのリスクが生じます。あわせて、各診断対象に対して弊社から実際にアクセス可能であるかどうかも、重要なポイントです。
また、「診断対象のURLやAPIが明確」であることに加えて、「診断対象のURLやAPIが正確」であることも非常に重要です。
ヒアリングシートに記載された診断対象と、実際にアクセスすべきURLやAPIが異なっている場合、本来不要な確認のやり取りが発生してしまいます。提供情報が正確でない場合、その都度の確認作業に時間が割かれるだけでなく、診断当日であれば、本来の診断作業に充てる時間が削られることになり、双方にとって不利益となる可能性があります。
2. リクエストパラメータで挙動が制御されるAPIを正確に伝える
GraphQLのように、単一のエンドポイントを使ってリクエストパラメータにより挙動を制御しているAPIを診断する場合も注意が必要です。
ヒアリングシートでは1つのエンドポイントだけが記載されていたものの、確認すると実際にはGraphQLが使われていたというケースがありました。
このような場合、診断対象は「エンドポイント単位」ではなく、Query名やMutation名単位での確認が必要になります。 診断の手間やコストに影響するため、該当するAPIがある場合は、その挙動を事前に共有いただくことで、診断員が適切な診断計画を立てやすくなります。
3. 対象URLへの遷移方法を正しく共有する
対象URLにたどり着くための手順が複雑だったり特殊条件が必要だったりすることがあります。
例えば「特定の権限のアカウントでのみ表示される画面」や「特定の申請がされている状態で特定のボタンを押すと遷移するページ」など、操作フローが不明確な場合は診断作業が中断してしまいます。
そういったケースでは、遷移条件や手順・操作方法などの補足情報をいただけると、非常に助かります。
4. アカウント数・ワンタイムURLを十分に準備する
アカウントやワンタイムURLは原則としてご提供いただいているのですが、個数が足りないという問題もよく発生します。
診断の観点からは、各権限ごとに4つ程度のアカウントがあると、認可関連の不備も含めた確認がしやすくなります。
また、ワンタイムURL等、使い回しができないものは、最低20個ほど用意しておくことが望ましいです。20個という数は一見多く感じられるかもしれませんが、診断中にURLが不足して作業が中断するリスクを避けられるため、ある程度の余裕を持たせておくと安心です。
なお、診断内容や対象機能によっては、より多くのアカウントやワンタイムURLが必要になる場合もあります。
5. 診断対象の環境に関する情報を正確に伝える
診断対象となる環境について、資料に記載された情報と実態が異なることもあります。
例えば、「アクセス制限なし」と書かれていたのに実際にはIP制限があったり、事前に聞いていなかったメンテナンスやシステムアップデートが行われていたりします。
こうした状況は、診断の遅延や再調整を引き起こす要因となりますので、環境に関する情報はできるだけ正確に記載されていると、診断の調整がスムーズになります。
6. スムーズなやり取りができる連絡体制を整える
診断期間中に確認事項が発生することは多く、その際のレスポンス体制も非常に重要です。
連絡先には、迅速にレスポンスが可能なメールアドレス、電話番号をご指定することが大切です。 特に、診断の最終日までに確認事項への回答が得られなかった場合、該当項目に関連する診断対象について、診断の完了が困難になる可能性があります。
弊社では、通常はメールでやり取りを行っていますが、本番環境で問題が発生し、診断を中断する必要が生じた場合には、電話でご連絡することもあります。その際に電話がつながらない場合、対応が遅れることで一般利用者に影響が及ぶ可能性があるため、可能な限り、連絡が取れる体制を事前に整えておいていただけると安心です。
7. メール送信機能の挙動を事前に確認・共有する
メール送信に関わる機能の診断では、診断者がメール本文・ヘッダーを確認出来るかどうかの確認が必要です。
例えば、アカウント作成時やメールアドレス変更時に、確認メールが送信される仕様の場合があります。 このとき、ヒアリングシートに該当画面のURLが記載されていても、メール本文を確認出来なければリンクの動作確認や登録処理が完了せず、診断を進めることができなくなります。
メール本文・ヘッダーを確認するための具体的な手段として、以下のような方法が考えられます。
-
診断対象の環境を、外部へのメール送信が可能な構成にする
-
Webメールなど、メールを受信できる環境を提供する
-
診断対象機能のHTTPレスポンス内に、実際に送信されるメール本文・ヘッダーを含める
これらの方法のいずれも採用が難しい場合は、該当機能を診断対象から除外することも検討する必要があります。
8. テストデータの準備と表示条件を明確にする
診断を行う上で、テストデータの有無は重要です。 診断対象の環境にテストデータが存在しない場合、画面遷移や機能の挙動を確認できないことがあります。
例えば：
-
検索結果が常に「0件」となる
-
お知らせ一覧に何も表示されない
-
購入履歴や申請履歴などの履歴がない
このような場合に、SQLインジェクションを代表とした、データの有無によって脆弱性を検出するタイプの脆弱性に対して、十分な診断作業が行えなくなる可能性があります。 このようなリスクを避けるためにも、事前にテストデータ準備を行っておくことが望ましいです。 また、データが表示される条件が複雑な場合は、その条件も明示いただけると非常に助かります。
まとめ
Webアプリの脆弱性診断を成功させるためには、事前準備が肝心です。
- 診断対象のURLやAPIを明確、正確にする
- リクエストパラメータで挙動が制御されるAPIを正確に伝える
- 対象URLへの遷移方法を正しく共有する
- アカウント数・ワンタイムURLを十分に準備する
- 診断対象環境に関する情報を正確に伝える
- スムーズなやり取りができる連絡体制を整える
- メール送信機能の挙動確認を事前に確認・共有する
- テストデータの準備と表示条件を明確にする
こうした準備を意識することで、診断を依頼される皆さまにとっても、短期間かつ高品質な診断結果を得やすくなるはずです。 事前準備をする際の一助になれば幸いです。