説明用の架空サンプル
報告書の構成と書き方を説明するために作った架空の例です。実在の会社・システム・調査結果ではありません。実際の報告書の内容と分量は、対象と調べる範囲によって変わります。
セキュリティ診断報告書 会員向けサービス（申込・カード決済）
この資料の構成
第1部判断のための資料
経営・事業のご担当者、決裁者の方向け
- 結論（推奨する対応の範囲、計画して直す範囲、残るリスク）と、その根拠
- 対応の順番（公開前・公開後1か月以内・その後）と、誰が動くか
- 対応しない場合のリスクと、確かめられたこと
- 今の構成
- 参考: 費用について
- 今回の範囲と、用語の説明
第2部修正のための資料
修正を担当する開発者の方向け
- 指摘の一覧
- 対象の技術情報と、ツールでの確認の結果
- 指摘ごとの該当箇所（ファイルと行）
- コード上で起きていることと、起きる条件
- 直したあとに満たすべき状態
- 問題なしと判断した確認の内容
第1部判断のための資料 経営・事業のご担当者、決裁者の方向け
1. 結論
結論
- 推奨する対応の範囲
- 公開の前に、「2. 対応の順番」の手順1〜12を済ませることを勧める。中でも、別の会員の申込内容が見える箇所（指摘1）、ソースコードに入っている本番の鍵の作り直し（指摘2）、決済のあとに請求と記録が食い違う箇所（指摘3）を先に直す。済ませたあと、試験環境で、会員ごとに見える範囲と、申込から決済までの流れを確かめ直す。
- 計画して直す範囲
- 公開後1か月以内に手順13〜18を進める。その後、手順19・手順20を計画して進める。
- 残るリスク
- 推奨する対応を済ませても、今回確かめなかったことに関わるリスクは残る。網羅的な侵入テストで分かること、アクセスが集中したときの動作、AWS の権限の設定とエラー監視サービスの設定のうち今回閲覧できなかったもの。また、依存しているライブラリには、公開後も新しい既知の脆弱性が見つかることがある。
- 要対応
- 16件
- 未確認
- 3件
- 問題なし
- 6件
- 公開前にやること
- 12件
左の3つは指摘の状態ごとの件数（合計25件）。右は「対応の順番」の手順のうち、公開前に行うものの件数（このほかの時期: 公開後1か月以内 6件・その後 2件）。状態の見方は「7. 今回の範囲と、用語の説明」。
判断の根拠
外から狙われる穴
- 管理画面はメールアドレスとパスワードだけで入れ、ログインの試行の回数も制限していない。管理画面に入れる人のパスワードが知られると、すべての会員の情報を見られる（指摘5）。
- ログインの状態を扱うライブラリに、深刻度が高い既知の脆弱性があり、このシステムはその脆弱性が起きる設定で使っている（指摘6）。
- 問い合わせフォームの確認画面で、細工した値を入れるとスクリプトが動く。悪意のあるリンクを開いた利用者の画面で、意図しない操作をされるおそれがある（指摘7）。
アプリの内部と設定の穴（ソースコードと設定を読んで見つけたもの）
- 申込の詳細画面で、URLの番号を変えると、ログインしている会員とは別の会員の申込内容（氏名、住所、契約の内容）が見られる（指摘1）。
- 本番の決済とメール送信の鍵が、ソースコードの中にそのまま書かれていて、リポジトリを持つ人は本番の鍵を使える（指摘2）。
- 決済が終わったあとの処理で失敗すると、請求されたのに契約の記録が残らない。申込の押し直しや、決済完了の画面の開き直しでは、同じ申込の決済や契約が重ねて作られる（指摘3・指摘4）。
- 本番用の設定に、試験用の決済のキーが入ったままで、このまま公開すると申込が実際の請求につながらない（指摘8）。決済の失敗を知らせる仕組みも見つからない（指摘9）。
確かめられたことと、直す範囲
- カード番号はこのシステムが受け取らない作りで、請求額も利用者が送る値で決めていない。データベースへの問い合わせに入力値をそのまま埋め込む箇所や、インターネットから直接届く設定は見つからなかった（指摘21〜指摘24）。
- 直す範囲は、申込の詳細画面の確認の処理、本番の鍵の作り直しと置き場所、決済の処理の改修（記録の食い違いと重なりを防ぐ）、管理画面のログインの守り、ライブラリの更新、問い合わせの確認画面の表示、決済のキーと失敗の知らせの設定。
未確認の事項
- バックアップから戻せるか。バックアップが毎日取られていることは確かめたが、戻す手順は試していない（指摘17）
- 管理画面に入れる人の範囲。AWS 側の設定で決まるため、ソースコードからは分からず、その設定を見る権限は用意できなかった（指摘18）
- エラー監視サービスの通知を受け取る人と設定。資料が届いていないため（指摘19）
結論を見直す条件: 試験環境にバックアップを戻して記録がそろわない場合は、指摘17を要対応にし、戻し方を公開前に直す。管理画面に入れる人に、退職した人や外部の人のアカウントが見つかった場合は、手順11を公開前のいちばん先に行う。エラー監視サービスから、決済の失敗がすでに担当者に届く設定になっていると分かった場合は、指摘9の重さを下げる。
サンプルの続きを読む（対応の順番・対応しない場合のリスク・第2部など）サンプルの続きを閉じる
2. 対応の順番
手順の番号は対応の順番。時期は「公開前」「公開後1か月以内」「その後」に分けた。「担当」は誰が動くかで、「開発・保守」は社内の開発者か、開発会社を指す。時期が同じ手順は、番号の順に進める。
- 1要対応申込の詳細画面で、別の会員の申込を表示しないようにする時期: 公開前
- 2要対応本番の鍵を作り直して古い鍵を無効にし、ソースコードの外に移す時期: 公開前
- 3要対応決済のあとの処理で失敗しても、請求と契約の記録が食い違わないようにする時期: 公開前
- 4要対応同じ申込の決済や契約が、重ねて作られないようにする時期: 公開前
- 5要対応管理画面に入る人の守りを決め、ログインの試行の回数を制限する時期: 公開前
- 6要対応ログインの状態を扱うライブラリを、修正された版に更新する時期: 公開前
- 7要対応問い合わせの確認画面で、入力した値がスクリプトとして動かないようにする時期: 公開前
- 8要対応決済のキーを、本番用のものに入れ替える時期: 公開前
- 9要対応決済の失敗を、担当者に知らせる設定を入れる時期: 公開前
- 10要対応AWS の最上位の利用者に、二要素認証を設定する時期: 公開前
- 11未確認管理画面に入れる人を確かめ、不要なアカウントを外す時期: 公開前
- 12未確認エラー監視サービスの通知を受け取る人と設定を確かめる時期: 公開前
- 13要対応ログを残す期間を延ばし、ほかの処理の失敗も知らせるようにする時期: 公開後1か月以内
- 14要対応ログアウトでログインの状態を切り、ログインの状態に期限を設ける時期: 公開後1か月以内
- 15要対応本番にデプロイする権限を、決めたブランチの処理だけが受け取れるようにする時期: 公開後1か月以内
- 16要対応深刻度が中の脆弱性があるライブラリを、修正された版に更新する時期: 公開後1か月以内
- 17要対応管理画面で、誰がいつ何を操作したかを記録に残す時期: 公開後1か月以内
- 18未確認バックアップを試験環境に戻し、記録がそろって戻ることを確かめる時期: 公開後1か月以内
- 19要対応解約した会員の本人確認書類を消す手順を決める時期: その後
- 20要対応データベースの保存時の暗号化を設定する時期: その後
3. 対応しない場合のリスク（抜粋）
要対応と未確認の指摘のうち、特に判断に関わるものを、重要な順に詳しく載せた。「そのほかの指摘」は、見出しと影響だけを載せた。開発者向けの詳細は、第2部の同じ番号を参照。
申込の詳細画面で、URLの番号を変えると、別の会員の申込内容が見られる
時期: 公開前調べ方ソースコード・設定試験環境での確認
- 対応しないと
- ログインしている会員なら誰でも、URLの番号を変えるだけで、ほかの会員の氏名、住所、契約の内容を見られる。個人情報の漏えいとして、会員への連絡や、個人情報保護委員会への報告が必要になることがある。
- 起きていること
- ソースコードで、会員ごとのデータを番号で探している処理（14か所）をすべて確かめた。ログインしている会員のものかを確かめていなかったのは、申込の詳細を返す処理の1か所だった。この処理は、URLに含まれる申込の番号でデータを探していて、申込の番号は1から順に振られている。試験環境で、会員Aでログインしたまま会員Bの申込の番号を開くと、会員Bの申込内容が表示されることを確かめた。
- 次に行うこと
- 申込の詳細を返す処理で、申込がログインしている会員のものかを確かめ、違う場合は表示しない。今後、会員ごとのデータを番号で探す処理を足すときも、同じ確かめを入れる。
本番の決済とメール送信の鍵と、署名用の秘密が、ソースコードの中にそのまま書かれている
時期: 公開前調べ方ソースコード・設定公式資料サービスの設定
- 対応しないと
- リポジトリや、その写しを持つ人は、本番の鍵を使える状態にある。決済代行サービスの公式資料によれば、この鍵では決済の情報の読み出しや返金ができ、メール送信の鍵では、このサービスの名前でメールを送れる。開発を手伝った外部の人や、今後リポジトリを渡す相手にも、鍵が渡ることになる。
- 起きていること
- ソースコードの変更履歴（git）で管理している設定ファイルに、決済代行サービスとメール送信サービスの本番の鍵と、パスワードの再設定に使う署名の秘密が、そのまま書かれている。サーバーの秘密の置き場所にも同じ鍵があるが、アプリはソースコードの値を先に読む。鍵の一覧と、誰が持ち、いつ変えるかを書いた資料は見つからなかった。
- 次に行うこと
- 公開の前に本番の鍵をすべて作り直し、古いものを無効にする。鍵はソースコードから外してサーバーの秘密の置き場所から読み、鍵ごとに持つ人と変える時期を決めて書き残す。
決済が終わったあとの処理で失敗すると、請求されたのに契約の記録が残らないおそれがある
時期: 公開前調べ方ソースコード・設定試験環境での確認
- 対応しないと
- 利用者には請求が届くのに、サービス側には契約がない状態になる。利用者からの問い合わせで初めて気づき、返金や記録の修正に手間がかかる。
- 起きていること
- ソースコードで申込の処理の順を追うと、決済代行サービスで決済を確定したあとに、契約の記録をデータベースに書き込む順になっている。書き込みに失敗したときに、決済を取り消す処理も、あとから記録を作り直す処理もない。試験環境で書き込みを失敗させると、決済だけが残ることを確かめた。
- 次に行うこと
- 決済の確定と契約の記録が食い違ったときに、決済を取り消すか、記録を作り直す仕組みを作る。決済代行サービスが決済の結果を知らせる仕組みを、記録の作り直しに使えるかを確かめる。
問い合わせフォームに入力した値が、確認画面でスクリプトとして動く
時期: 公開前調べ方ツールでの確認試験環境での確認
- 対応しないと
- 悪意のある人が細工したリンクを用意し、利用者がそれを開くと、利用者の画面でスクリプトが動く。ログインしている会員なら、その会員として意図しない操作をされるおそれがある（クロスサイトスクリプティング）。
- 起きていること
- 問い合わせフォームの確認画面は、入力された値を、スクリプトとして動かないように変換せずに表示している。試験環境に対するツールでの自動の確認で警告が出たため、手で再現して確かめた。お名前の欄にスクリプトを含む値を入れて確認画面に進むと、そのスクリプトが動くことを確かめた。
- 次に行うこと
- 確認画面で、入力された値をスクリプトとして動かないように変換してから表示する。入力された値を画面に表示しているほかの箇所にも、同じ問題がないかを一覧にして確かめる。
そのほかの指摘
申込のボタンの押し直しや、決済完了の画面の開き直しで、同じ申込の決済や契約が重ねて作られる
時期: 公開前通信が遅いときに申込のボタンを押し直したり、決済完了の画面を開き直したりすると、同じ利用者に同じ金額が2回請求され、契約と領収のメールも重ねて作られる。返金の手間がかかり、利用者の信頼も損ねる。
管理画面は、メールアドレスとパスワードだけで入れ、ログインの試行の回数も制限していない
時期: 公開前管理画面に入れる人のパスワードが、使い回しや推測で知られると、どこからでもログインでき、すべての会員の氏名・住所・契約の内容を見られる。ログインの試行の回数を制限していないため、パスワードを総当たりで試されても止まらない。
管理画面に入れる人の範囲が分からない
時期: 公開前退職した人や、開発を手伝った外部の人が管理画面に入れる状態だと、会員の個人情報や契約の記録を見られたり、書き換えられたりするおそれがある。
4. 確かめられたこと
今回の方法と範囲で確かめ、問題が見つからなかったもの。安全であることの保証ではない。何をどう確かめたかは、第2部「問題なしと判断した確認の内容」に載せた。
| 番号 | 確かめた結果 | 調べ方 |
|---|---|---|
| 指摘20 | HTTPSと、セキュリティに関わる主なヘッダーが、すべての画面で同じ設定になっていた | ヘッダー・HTTPSサービスの設定 |
| 指摘21 | カード番号は決済代行サービスの部品で受け取っていて、このシステムのサーバーとログを通らなかった | ソースコード・設定試験環境での確認 |
| 指摘22 | データベースへの問い合わせに、入力値をそのまま使う箇所は見つからなかった | ソースコード・設定ツールでの確認 |
| 指摘23 | 請求額は、サーバー側でプランから決めていて、利用者が送る値を使っていなかった | ソースコード・設定 |
| 指摘24 | データベースに、インターネットから直接届く設定は見つからなかった | サービスの設定 |
| 指摘25 | 本人確認書類を置くファイルの置き場所は、公開の設定になっていなかった | サービスの設定 |
5. 今の構成
| 要素 | 内容 | 状態 |
|---|---|---|
| Webアプリ（会員向けの画面と管理画面） | 申込の詳細、決済のあとの処理、管理画面のログイン、問い合わせの確認画面に、直すことがある（指摘1・3・4・5・7） | 要対応 |
| 決済 | カード番号は決済代行サービスの部品で受け取っている（指摘21）。本番の鍵がソースコードにあり、重複を防ぐ仕組みを使っていない（指摘2・4） | 要対応 |
| データベース | 1台で動き、自動バックアップは毎日・7日分。戻す手順は試していない。保存時の暗号化がない（指摘16・17） | 要対応 |
| AWS のアカウント | 最上位の利用者に二要素認証がない。管理画面に入れる人は、AWS 側の設定で決まる（指摘11・18） | 要対応 |
| 監視と通知 | 決済の失敗を知らせる仕組みが見つからず、ログは3日で消える。エラー監視サービスの設定は確かめていない（指摘9・19） | 要対応 |
| デプロイ | 本番にデプロイする権限を、どのブランチの処理からでも受け取れる（指摘12） | 要対応 |
6. 参考: 費用について
指摘とは分けて、参考として、費用に関わって気づいたことを書いた。金額の見積もりではない。
- 試験環境のデータベースとサーバーが、使わない夜間と休日も動き続けている
- 開発の途中で作ったサーバーの写しが3つと、どこにもつながっていないディスクが1つ残っている
- データベースの詳しい監視を、本番と試験環境の両方で有効にしている
7. 今回の範囲と、用語の説明
状態の見方
- 要対応
- 確認できた問題があり、対応が必要
- 未確認
- 今回の範囲では確かめられなかった。追加の確認が必要
- 問題なし
- 今回の方法と範囲で確かめ、問題は見つからなかった
調べ方の見方
外からの攻撃を見る観点
OWASP ASVS 5.0.0（Web アプリケーションの安全性を確かめる項目を、非営利団体 OWASP がまとめたもの）の L2（253件）を、このシステムに合わせた水準として参照した。ASVS への準拠を確かめたもの・認証したものではない。
ASVS の項目ごとの判定: 満たす 128件・満たさない 41件・該当しない 62件・未確認 22件。件数は ASVS の項目の数で、指摘の件数ではない。該当しないは、使っていない機能に当たる項目。指摘に関わる項目の番号は、第2部の各指摘に載せた。
今回の範囲に含めなかったこと
- 網羅的な侵入テスト、負荷試験、修正作業
- スキャンで見つかった脆弱性の、具体的な修正方針の検討と、修正したあとの動作確認
- 費用の見積もり
- 本番環境に対して攻撃を試すこと
- 公開してよいかの可否の判定
用語の説明
第2部修正のための資料 修正を担当する開発者の方向け
指摘の番号は第1部と共通。修正の方法と、直したあとの動作確認は今回の範囲外。「直したあとに満たすべき状態」は、修正を担当する方が確かめるときの目安として書いている。
8. 指摘の一覧
| 番号 | 状態 | 指摘 | 対応時期 | 対応の順番 |
|---|---|---|---|---|
| 指摘1 | 要対応 | 申込の詳細画面で、URLの番号を変えると、別の会員の申込内容が見られる | 公開前 | 手順1 |
| 指摘2 | 要対応 | 本番の決済とメール送信の鍵と、署名用の秘密が、ソースコードの中にそのまま書かれている | 公開前 | 手順2 |
| 指摘3 | 要対応 | 決済が終わったあとの処理で失敗すると、請求されたのに契約の記録が残らないおそれがある | 公開前 | 手順3 |
| 指摘4 | 要対応 | 申込のボタンの押し直しや、決済完了の画面の開き直しで、同じ申込の決済や契約が重ねて作られる | 公開前 | 手順4 |
| 指摘5 | 要対応 | 管理画面は、メールアドレスとパスワードだけで入れ、ログインの試行の回数も制限していない | 公開前 | 手順5 |
| 指摘6 | 要対応 | ログインの状態を扱うライブラリに、深刻度が高い既知の脆弱性がある | 公開前 | 手順6 |
| 指摘7 | 要対応 | 問い合わせフォームに入力した値が、確認画面でスクリプトとして動く | 公開前 | 手順7 |
| 指摘8 | 要対応 | 本番用の設定に、試験用の決済のキーが入ったままになっている | 公開前 | 手順8 |
| 指摘9 | 要対応 | 決済の失敗を社内に知らせる仕組みが見つからず、ログも3日で消える | 公開前・公開後1か月以内 | 手順9・手順13 |
| 指摘10 | 要対応 | ログアウトしてもサーバー側でログインの状態を切れず、ログインの状態に期限もない | 公開後1か月以内 | 手順14 |
| 指摘11 | 要対応 | AWS の最上位の利用者に、二要素認証が設定されていない | 公開前 | 手順10 |
| 指摘12 | 要対応 | 本番にデプロイする権限を、どのブランチの処理からでも受け取れる | 公開後1か月以内 | 手順15 |
| 指摘13 | 要対応 | 深刻度が中の既知の脆弱性があるライブラリが2件ある | 公開後1か月以内 | 手順16 |
| 指摘14 | 要対応 | 解約した会員の本人確認書類を消す仕組みがない | その後 | 手順19 |
| 指摘15 | 要対応 | 管理画面で、誰がいつ何を操作したかを記録していない | 公開後1か月以内 | 手順17 |
| 指摘16 | 要対応 | データベースの保存時の暗号化が設定されていない | その後 | 手順20 |
| 指摘17 | 未確認 | バックアップから戻せるかが分からない | 公開後1か月以内 | 手順18 |
| 指摘18 | 未確認 | 管理画面に入れる人の範囲が分からない | 公開前 | 手順11 |
| 指摘19 | 未確認 | エラー監視サービスの通知を受け取る人と設定が分からない | 公開前 | 手順12 |
| 指摘20 | 問題なし | HTTPSと、セキュリティに関わるヘッダーが設定されている | — | — |
| 指摘21 | 問題なし | カード番号を、このシステムが受け取らない作りになっている | — | — |
| 指摘22 | 問題なし | データベースへの問い合わせに、入力値をそのまま埋め込んでいない | — | — |
| 指摘23 | 問題なし | 請求額を、利用者が送る値で決めていない | — | — |
| 指摘24 | 問題なし | データベースに、インターネットから直接届く設定はない | — | — |
| 指摘25 | 問題なし | ファイルの置き場所が、公開の設定になっていない | — | — |
9. 対象の技術情報と、ツールでの確認
依存関係のスキャン
| 深刻度 | 対象 | このシステムでの使われ方 | 対応の目安 |
|---|---|---|---|
| 高・1件 | ログインの状態を扱うライブラリ | ログインと、ログイン中の会員の確認で動く。脆弱性が起きる条件に当てはまる設定で使っている | 公開前に更新する（指摘6） |
| 中・2件 | 通信と文字列の処理のライブラリ | 本番の全画面で動く | 公開後1か月以内に更新する（指摘13） |
| 低・1件 | 開発用の道具 | 本番では動かない | 急ぐ必要は小さい。開発環境を更新するときに対応する |
スキャンで分かるのは、公開されている既知の脆弱性に限られる。見つかったものは、このシステムでの使われ方と照らし合わせて、対応の目安を決めた。実際の報告書では、パッケージ名、今の版と修正された版、CVE番号、CVSSの値も書く。
試験環境に対する自動の確認
ツールの警告は、ソースコードと照らし合わせ、実害があるものだけを報告に残した。
10. 指摘の詳細（抜粋）
申込の詳細画面で、URLの番号を変えると、別の会員の申込内容が見られる
対応時期: 公開前 対応の順番: 手順1 ASVS: V8.2.2・V8.4.1 調べ方ソースコード・設定試験環境での確認
- 該当箇所
src/app/api/applications/[id]/route.ts:12-34src/app/api/applications/route.ts:9-21- コード上で起きていること
- 申込の詳細を返す処理は、URLの番号で申込を1件探していて（18行目）、条件にログインしている会員の番号を含めていない。一覧を返す処理は、ログインしている会員の番号で絞っている。会員ごとのデータを番号で探す処理は14か所あり、絞っていないのはこの1か所だけだった。申込の番号は、データベースの連番。
- 起きる条件
- 会員としてログインし、自分のものではない申込の番号で詳細を開く。
- 業務への影響
- ログインしている会員なら誰でも、ほかの会員の氏名、住所、契約の内容を見られる。番号は連番なので、対象はすべての会員の申込に及ぶ。
- 直したあとに満たすべき状態
- ログインしている会員のものではない申込の番号を開くと、内容が返らないこと。自分の申込は、これまでどおり開けること。
申込のボタンの押し直しや、決済完了の画面の開き直しで、同じ申込の決済や契約が重ねて作られる
対応時期: 公開前 対応の順番: 手順4 ASVS: V2.3.3・V2.3.4 調べ方ソースコード・設定公式資料試験環境での確認
- 該当箇所
src/app/api/applications/route.ts:42-88src/app/apply/complete/page.tsx:20-57src/components/apply-button.tsx:15-31- コード上で起きていること
- 申込のたびに、決済代行サービスへ新しい決済の作成を依頼していて、重複を防ぐためのキー（冪等キー）を送っていない。決済完了の画面は、開かれるたびに契約の記録と領収のメールを作り、その決済をすでに処理したかを確かめていない。申込のボタンは、送信中も押せる。
- 起きる条件
- 申込の送信中にボタンを押し直す。通信が途切れて画面を読み込み直し、もう一度送信する。または、決済完了の画面を開き直す。
- 業務への影響
- 同じ利用者に同じ金額が2回請求され、契約と領収のメールも重ねて作られる。返金の手間がかかり、利用者の信頼も損ねる。
- 直したあとに満たすべき状態
- 同じ申込を何回送っても、決済が1件だけ作られること。決済完了の画面を開き直しても、契約と領収のメールが1件のままであること。
11. 問題なしと判断した確認の内容（抜粋）
HTTPSと、セキュリティに関わるヘッダーが設定されている
試験環境の画面を読み込み、証明書、HTTPからHTTPSへの転送、セキュリティに関わる主なヘッダーを確かめた。本番環境のサーバーの設定とソースコードとも突き合わせ、公開後も同じ設定になることを確かめた。
カード番号を、このシステムが受け取らない作りになっている
カード番号の入力欄は、決済代行サービスが用意した部品の中にあり、入力されたカード番号は、このシステムのサーバーを通らない。試験環境で申込を行い、サーバーに届く内容とログに、カード番号が含まれないことを確かめた。
データベースへの問い合わせに、入力値をそのまま埋め込んでいない
検索や申込など、利用者が入力した値を使う問い合わせは、すべて値を文と分けて渡す書き方になっている。入力値をつなげて問い合わせの文を組み立てている箇所は、見つからなかった。試験環境に対するツールでの自動の確認では、検索画面で1件、この問題を疑う反応が出た。手で再現して確かめたところ、入力の誤りを知らせる通常の画面で、問い合わせの文は組み立て直されていなかった。
このサンプルは、報告書の一部を抜き出して短くまとめたものです。報告書は、今回の方法と範囲で確かめた内容をまとめたもので、システムが安全であることを保証するものではありません。