Webサイトの安全を調べる前に、調べてよい場所を決める

たとえば、依頼の内容が「AさんがBさんの書類を読めてしまわないか」だったとします。その確認には、Aさん用とBさん用の練習アカウント、架空の書類、書類を開く操作が必要です。ここでいう書類とは、請求書や売上表など、仕事で使う書類のことです。

この依頼だけでは、管理画面を全部探したり、大量の書類をダウンロードしたりしてよいとはいえません。知りたいことを一つ決め、その確認に必要な場所と操作だけを選びます。

これは調べる範囲を決める例です。今回の配布資料ではGET /healthの動作確認を頼まれた場面を使い、三つの予定が許可書に合うか判断します。

依頼した人に、そのサイトを調べる許可を出せるか確認します。必要なら、サイトの所有者や運用担当者にも聞きます。同じ会社の画面に見えても、決済サービスや他社と共用する設備、別の人のアカウントは、別の許可が必要なことがあります。

調べてよいサイト、試してよい方法、触れてはいけない場所を、書面などで残します。サービスの利用条件も確認します。分からない場所は、確認が済むまで操作しません。後で書くJSONは約束を確認しやすくする設定であり、書いたから現実の作業が許可されるわけではありません。

Webサイトの住所を表すURLを見ます。https://training.example.test は通信相手です。似た文字を含む別の名前は、同じ相手とは限りません。通信方法・ホスト名・ポート番号の三つを合わせてoriginと呼びます。httpsのポート番号を省略した場合は443です。

/reports は、相手のどのページや機能を使うかを表すパスです。「/reports以下を調べてよい」という約束でも、/reports-oldという別の名前は含みません。書類を読むGETが許可されても、データを送るPOSTや削除を頼むDELETEまで使えるわけではありません。

URLと操作名だけでは、使う人や扱うデータまでは決まりません。練習用のアカウントとデータも、別に指定します。

作業する日・開始・終了・時刻帯を決めます。終了時刻を含むかも合意します。また毎秒何回、全体で合計何回、同時に何件までかは別の制限です。送り直しや失敗した要求の数え方も揃えます。

今回のscenario.txtには、対象127.0.0.1、GET /health、13時から14時、毎秒1回以下という架空の許可と予定A・B・Cがあります。この資料の条件で判断します。別の時間帯や合計回数の例を、今回の依頼へ混ぜないでください。

使えなくなった、本物の個人情報が見えた、範囲を増やす必要が出た、といったときの停止・連絡を始める前に決めます。元に戻って見えても自分だけで再開を決めず、担当者の確認を待ちます。

今回の資料では500の応答が出たら停止する約束です。answer.jsonへ停止後の対応を書きます。eventsやstopOnという設定を操作する画面はなく、実際にエラーを起こしたり連絡を送ったりする必要もありません。

作業した日時、調べた場所、操作、使った練習アカウント、予想した結果、実際の結果を記録します。途中で止めた場合は、その時点も残します。時刻には、日本時間などの基準も付けます。

顧客情報やログインに使うトークンを、そのまま報告へ貼らないようにします。必要な部分以外を伏せ、保管場所、読める人、保管期間、削除方法を関係者と決めます。

「返事があった」「書類を読めた」「操作した人物が分かった」は別の事実です。実際に確かめたことと、まだ分からないことを分けて伝えます。

scenario.txtの許可書を読み、予定A・B・Cについて相手・パス・操作・時間・回数を比べます。answer.jsonの項目名はそのままに、実行してよい予定の一覧と、止める理由を記入します。

JSONの[]は一覧、"A"は予定の名前を表す文字です。実行する予定に入れなかったものは、どの条件が合わなかったかを書きます。これは計画の判断で、書いたアドレスへ要求を送る処理ではありません。

この練習は、書いたURLへ実際に接続しません。現実には、名前から通信先を探すDNS、別URLへ案内するリダイレクト、IPアドレスの範囲、検索条件で指定するデータ、利用する会社の区分、障害の見つけ方も確認します。

読み方が曖昧なURLは、都合よく読み替えて「調べてよい」と判断しません。担当者に確認します。最後に人が、目的、許可した人、サイトと除外場所、アカウント、方法、日程、回数、停止・連絡・再開の手順、記録の扱いを確認します。練習で合格しても、この確認や現実の作業許可を得たことにはなりません。