説明用の架空サンプル
報告書の構成と書き方を説明するために作った架空の例です。実在の会社・システム・調査結果ではありません。書き方が分かるように、指摘の件数を絞っています。これまでの診断では、1つのシステムで指摘が70件前後になりました。実際の報告書の内容と分量は、対象と調べる範囲によって変わります。
セキュリティ診断報告書 会員向けサービス（申込・カード決済）
この資料の構成
第1部判断のための資料
経営・事業のご担当者、決裁者の方向け
- 診断結果のまとめ（観点ごとの状態と、いちばん大きいリスク）
- 結論（推奨する対応の範囲、残るリスク）と、その根拠
- 対応しない場合のリスクと、確かめられたこと
- 参考: 表示の速さ（Core Web Vitals）
- 参考: 費用について
- 今回の範囲と、用語の説明
第2部修正のための資料
修正を担当する開発者の方向け
- 指摘の一覧
- 対象の技術情報と、ツールでの確認の結果
- 指摘ごとの該当箇所（ファイルと行）
- コード上で起きていることと、起きる条件
- 直す場合に行うことと、直したあとに満たすべき状態
- 問題なしと判断した確認の内容
第1部判断のための資料 経営・事業のご担当者、決裁者の方向け
1. 診断結果のまとめ
観点ごとに、今回の方法と範囲で分かったことをまとめた。状態は、その観点の指摘の状態と重要度から決まる（表の下の注記）。「今回の範囲では問題は見つからなかった」は、安全であることの保証ではない。重要度の見方は「7. 今回の範囲と、用語の説明」。
| 観点 | 状態 | ひとことで | 指摘の件数 |
|---|---|---|---|
| 外から不正に使われないか | 大きな問題がある | 本番の鍵がソースコードに書かれ、申込の詳細画面では URLの番号を変えると別の会員の申込内容が見られる。管理画面に入れる人の範囲は確かめられなかった（指摘1・指摘2・指摘3）。 |
|
| お金とデータの扱いで、食い違いが起きないか | 大きな問題がある | 決済のあとの処理で失敗すると請求と契約の記録が食い違い、押し直しで決済が重ねて作られる。本番用の設定に試験用の決済のキーが入っている（指摘4・指摘5・指摘7）。 |
|
| 止まったとき・壊れたときに、気づけて戻せるか | 問題がある | 決済の失敗を社内に知らせる仕組みが見つからず、ログも3日で消える。バックアップから戻せるかと、エラー監視サービスの通知の設定は確かめられなかった（指摘10・指摘16・指摘17）。 |
|
| 持たなくてよいデータを、持っていないか | 問題がある | 解約した会員の本人確認書類を消す仕組みがない（指摘19）。カード番号は、このシステムが受け取らない作りだった（指摘24）。 |
|
| 利用が増えても、待たされずに使えるか | 問題がある | 管理画面の申込の一覧は、申込1件ごとに会員の情報を問い合わせ、取得する件数にも上限がない。申込が増えるほど表示が遅くなる作りになっている（指摘12）。 |
|
| 担当が変わっても、安全に直し続けられるか | 問題がある | 契約の状態を変える処理が4か所に分かれていて、自動テストがない。解約や支払いの扱いを変えるときに、直し漏れで記録が食い違うおそれがある（指摘11・指摘22）。 |
|
状態の決め方: 重要度が Critical か High の要対応があれば「大きな問題がある」、ほかの要対応があれば「問題がある」、要対応がなく未確認があれば「確かめられなかったことがある」、問題なしだけなら「今回の範囲では問題は見つからなかった」。
いちばん大きいリスク
- 本番の決済とメール送信の鍵が、ソースコードの中にそのまま書かれている。リポジトリを読める開発の協力会社の人を含め、リポジトリを持つ人は本番の鍵を使える（指摘1）。
- ログインしている会員が URLの番号を変えると、ほかの会員の氏名、住所、契約の内容が表示される（指摘3）。
- 決済が終わったあとの処理で失敗すると、請求されたのに契約の記録が残らない。申込の押し直しなどで、同じ申込の決済や契約が重ねて作られる（指摘4・指摘5）。
- 要対応
- 19件
- 未確認
- 3件
- 問題なし
- 6件
- うち Critical・High
- 6件
左の3つは指摘の状態ごとの件数（合計28件）。右は、要対応のうち重要度が Critical か High のもの。要対応19件の重要度は Critical 1件・High 5件・Medium 8件・Low 5件、未確認3件の問題があった場合の重要度は Critical 1件・Medium 2件。状態と重要度の見方は「7. 今回の範囲と、用語の説明」。
サンプルの続きを読む（結論・対応しない場合のリスク・第2部など）サンプルの続きを閉じる
2. 結論
結論
- 推奨する対応の範囲
- 重要度が Critical・High の要対応6件を直すことを勧める。ソースコードに入っている本番の鍵（指摘1）、別の会員の申込内容が見える箇所（指摘3）、請求と記録の食い違いと重なる決済（指摘4・指摘5）、ライブラリの脆弱性と本番用の決済のキー（指摘6・指摘7）。あわせて、Medium のうち、決済の失敗に気づけるかに関わる知らせの仕組み（指摘10）も、直すことを勧める。管理画面に入れる人（指摘2）とエラー監視サービスの通知の設定（指摘17）は、確かめることを勧める。直した場合は、試験環境で、会員ごとに見える範囲と申込から決済までの流れを確かめ直すことを勧める。
- 残るリスク
- 推奨する対応を済ませても、今回確かめなかったことに関わるリスクは残る。網羅的な侵入テストで分かること、アクセスが集中したときの動作、AWS の権限の設定とエラー監視サービスの設定のうち今回閲覧できなかったもの。また、依存しているライブラリには、公開後も新しい既知の脆弱性が見つかることがある。
判断の根拠
外から狙われる穴
- ログインの状態を扱うライブラリに、深刻度が High の既知の脆弱性があり、このシステムはその脆弱性が起きる設定で使っている（指摘6）。
- 管理画面はメールアドレスとパスワードだけで入れ、ログインの試行の回数も制限していない。管理画面に入れる人のパスワードが知られると、すべての会員の情報を見られる（指摘8）。
- 問い合わせフォームの確認画面で、細工した値を入れるとスクリプトが動く。悪意のあるリンクを開いた利用者の画面で、意図しない操作をされるおそれがある（指摘9）。
アプリの内部と設定の穴（ソースコードと設定を読んで見つけたもの）
- 本番の決済とメール送信の鍵が、ソースコードの中にそのまま書かれていて、リポジトリを持つ人は本番の鍵を使える（指摘1）。管理画面に入れる人の範囲は、確かめられなかった（指摘2）。
- 申込の詳細画面で、URLの番号を変えると、ログインしている会員とは別の会員の申込内容（氏名、住所、契約の内容）が見られる（指摘3）。
- 決済が終わったあとの処理で失敗すると、請求されたのに契約の記録が残らない。申込の押し直しや決済完了の画面の開き直しでは、同じ申込の決済や契約が重ねて作られる（指摘4・指摘5）。
- 本番用の設定に試験用の決済のキーが入ったままで、このまま公開すると申込が実際の請求につながらない（指摘7）。決済の失敗を知らせる仕組みも見つからない（指摘10）。
- 契約の状態を変える処理が4か所に分かれていて自動テストがなく、管理画面の申込の一覧は申込が増えるほど遅くなる作りになっている。どちらも、それだけで今の利用者に事故が起きるものではないため、推奨する対応の範囲には入れていない（指摘11・指摘12）。
確かめられたこと
- カード番号はこのシステムが受け取らない作りで、請求額も利用者が送る値で決めていない。データベースへの問い合わせに入力値をそのまま埋め込む箇所や、インターネットから直接届く設定は見つからなかった（指摘24〜指摘27）。
未確認の事項
- 管理画面に入れる人の範囲。AWS 側の設定で決まるため、ソースコードからは分からず、その設定を見る権限は用意できなかった（指摘2）
- バックアップから戻せるか。バックアップが毎日取られていることは確かめたが、戻す手順は試していない（指摘16）
- エラー監視サービスの通知を受け取る人と設定。資料が届いていないため（指摘17）
結論を見直す条件: 管理画面に入れる人に、退職した人や外部の人のアカウントが見つかった場合は、そのアカウントでの操作の記録を確かめることを、推奨する対応の範囲に加える。試験環境にバックアップを戻して記録がそろわない場合は、指摘16を要対応にし、戻す手順を整えることを推奨する対応の範囲に加える。エラー監視サービスから、決済の失敗がすでに担当者に届く設定になっていると分かった場合は、指摘10のうち知らせの仕組みを、推奨する対応の範囲から外す。
3. 対応しない場合のリスク（抜粋）
要対応と未確認の指摘のうち、特に判断に関わるものを重要な順に詳しく載せた。「そのほかの指摘」は、見出しと影響だけを載せた。未確認の重要度は、確かめた結果、問題があった場合の重要度。開発者向けの詳細は、第2部の同じ番号を参照。
本番の決済とメール送信の鍵と、署名用の秘密が、ソースコードの中にそのまま書かれている
調べ方ソースコード・設定公式資料サービスの設定
- 対応しないと
- リポジトリやその写しを持つ人は、本番の鍵を使える状態にある。決済代行サービスの公式資料によれば、この鍵では決済の情報の読み出しや返金ができ、メール送信の鍵では、このサービスの名前でメールを送れる。今後リポジトリを渡す相手にも、鍵が渡ることになる。
- 起きていること
- ソースコードの変更履歴（git）で管理している設定ファイルに、決済代行サービスとメール送信サービスの本番の鍵と、パスワードの再設定に使う署名の秘密が、そのまま書かれている。リポジトリは、開発を手伝った協力会社の2人も読める設定になっている。サーバーの秘密の置き場所にも同じ鍵があるが、アプリはソースコードの値を先に読む。鍵の一覧と、誰が持ち、いつ変えるかを書いた資料は見つからなかった。
- 直す場合に行うこと
- 本番の鍵をすべて作り直し、古いものを無効にする。鍵はソースコードから外してサーバーの秘密の置き場所から読み、鍵ごとに持つ人と入れ替えの決まりを書き残す。
管理画面に入れる人の範囲が分からない
調べ方ソースコード・設定
- 確かめないと
- 退職した人や開発を手伝った外部の人が管理画面に入れる状態だと、会員の個人情報や契約の記録を見られたり、書き換えられたりするおそれがある（誰が入れるかは確かめていない）。
- 起きていること
- 管理画面に入れる人は、ソースコードではなく、AWS 側の利用者と権限の設定で決まっている。今回はその設定を見る権限を用意できなかったため、確かめていない。
- 確かめる場合に行うこと
- AWS の管理画面で、管理画面に入れる利用者の一覧を確かめ、今は使っていないものを外す。
申込の詳細画面で、URLの番号を変えると、別の会員の申込内容が見られる
調べ方ソースコード・設定動作の確認
- 対応しないと
- ログインしている会員なら誰でも、URLの番号を変えるだけで、ほかの会員の氏名、住所、契約の内容を見られる。個人情報の漏えいとして、会員への連絡や個人情報保護委員会への報告が必要になることがある。
- 起きていること
- ソースコードで、会員ごとのデータを番号で探している処理（14か所）をすべて確かめた。ログインしている会員のものかを確かめていなかったのは、申込の詳細を返す処理の1か所だった。この処理は、URLに含まれる申込の番号でデータを探していて、申込の番号は1から順に振られている。試験環境で、会員Aでログインしたまま会員Bの申込の番号を開くと、会員Bの申込内容が表示されることを確かめた。
- 直す場合に行うこと
- 申込の詳細を返す処理で、申込がログインしている会員のものかを確かめ、違う場合は表示しない。今後、会員ごとのデータを番号で探す処理を足すときも、同じ確かめを入れる。
決済が終わったあとの処理で失敗すると、請求されたのに契約の記録が残らないおそれがある
調べ方ソースコード・設定動作の確認
- 対応しないと
- 利用者には請求が届くのに、サービス側には契約がない状態になる。利用者からの問い合わせで初めて気づき、返金や記録の修正に手間がかかる。
- 起きていること
- ソースコードで申込の処理の順を追うと、決済代行サービスで決済を確定したあとに、契約の記録をデータベースに書き込む順になっている。書き込みに失敗したときに、決済を取り消す処理も、あとから記録を作り直す処理もない。試験環境で書き込みを失敗させると、決済だけが残ることを確かめた。
- 直す場合に行うこと
- 決済の確定と契約の記録が食い違ったときに、決済を取り消すか、記録を作り直す仕組みを作る。決済代行サービスが決済の結果を知らせる仕組みを、記録の作り直しに使えるかを確かめる。
そのほかの指摘（抜粋）
申込のボタンの押し直しや決済完了の画面の開き直しで、同じ申込の決済や契約が重ねて作られる
通信が遅いときに申込のボタンを押し直したり、決済完了の画面を開き直したりすると、同じ利用者に同じ金額が2回請求され、契約と領収のメールも重ねて作られる。返金の手間がかかり、利用者の信頼も損ねる。
問い合わせフォームに入力した値が、確認画面でスクリプトとして動く
悪意のある人が細工したリンクを用意し、利用者がそれを開くと、利用者の画面でスクリプトが動く。ログインしている会員なら、その会員として意図しない操作をされるおそれがある（クロスサイトスクリプティング）。
契約の状態（申込中・有効・解約）を変える処理が4か所に分かれていて、自動テストがない
解約や支払いの失敗の扱いを変えるときは、4か所を同じように直す必要がある。直し漏れがあると、解約した会員に請求が続く、支払っていない会員が使い続けられるといった食い違いが起きるおそれがある。テストがないため、食い違いに気づく仕組みもない。
管理画面の申込の一覧で、申込1件ごとに会員の情報を問い合わせていて、取得する件数にも上限がない
申込が増えるほど一覧の表示が遅くなり、ある時点から時間内に表示できなくなるおそれがある。申込の確認や問い合わせへの対応が滞る。
4. 確かめられたこと
今回の方法と範囲で確かめ、問題が見つからなかったもの。安全であることの保証ではない。何をどう確かめたかは、第2部「問題なしと判断した確認の内容」に載せた。
| 番号 | 確かめた結果 | 調べ方 |
|---|---|---|
| 指摘23 | HTTPSとセキュリティに関わる主なヘッダーが、すべての画面で同じ設定になっていた | ヘッダー・HTTPSサービスの設定 |
| 指摘24 | カード番号は決済代行サービスの部品で受け取っていて、このシステムのサーバーとログを通らなかった | ソースコード・設定動作の確認 |
| 指摘25 | データベースへの問い合わせに、入力値をそのまま使う箇所は見つからなかった | ソースコード・設定ツールでの確認 |
| 指摘26 | 請求額は、サーバー側でプランから決めていて、利用者が送る値を使っていなかった | ソースコード・設定 |
| 指摘27 | データベースに、インターネットから直接届く設定は見つからなかった | サービスの設定 |
| 指摘28 | 本人確認書類を置くファイルの置き場所は、公開の設定になっていなかった | サービスの設定 |
5. 参考: 表示の速さ
指摘とは分けて、参考として、合意したページの表示の速さを、Google が示す Core Web Vitals の指標で示した。評価は Google の基準（良好・改善が必要・不良）に当てはめたもの。重要度は Information（指摘ではない参考）。
| ページ | 値の出どころ | LCP | INP（手元は TBT） | CLS |
|---|---|---|---|---|
| 試験環境のトップページ | 手元の測定 | 2.1秒（良好） | 120ms（基準なし） | 0.02（良好） |
| 試験環境の申込の画面 | 手元の測定 | 2.8秒（改善が必要） | 340ms（基準なし） | 0.04（良好） |
使ったもの: Lighthouse 13.5.0（モバイルの既定の設定、3回の中央値）。実際の利用者の値は、公開前のためなし。LCP はいちばん大きな表示が出るまでの時間、INP は操作してから画面が変わるまでの時間、CLS は表示の途中で画面の中身がずれる量。手元の測定は、cyfr の環境でモバイルの端末を模擬して3回測った中央値で、回線や機械の速さで変わり、実際の利用者の体感と同じではない。手元の測定では INP を測れないため、代わりの目安として TBT（読み込みの間に、操作に応えられない時間の合計。基準はない）を出した。
6. 参考: 費用について
指摘とは分けて、参考として、費用に関わって気づいたことを書いた。重要度は Information（指摘ではない参考）。金額の見積もりではない。
- Information試験環境のデータベースとサーバーが、使わない夜間と休日も動き続けている
- Information開発の途中で作ったサーバーの写しが3つと、どこにもつながっていないディスクが1つ残っている
- Informationデータベースの詳しい監視を、本番と試験環境の両方で有効にしている
7. 今回の範囲と、用語の説明
状態の見方
- 要対応
- 確認できた問題があり、対応が必要
- 未確認
- 今回の範囲では確かめられなかった。追加の確認が必要
- 問題なし
- 今回の方法と範囲で確かめ、問題は見つからなかった
重要度の見方
- Critical
- 個人情報・ほかの利用者のデータ、お金、本番の鍵や管理の権限、止まって戻せないこと、のどれかに届き、ログインせずに外からの要求だけで起きるもの、または起きる条件をすでに満たしている人がいるもの
- High
- 同じ結果に届き、ログインした利用者なら誰でも起こせるもの、ふつうの操作やよくある失敗で起きるもの
- Medium
- 同じ結果に届くが、ほかの条件が重ならないと起きないもの。届く相手が特定の利用者に限られるもの。気づくのや戻すのが遅れるもの
- Low
- それだけでは上の結果に届かないもの（備え・運用の改善など）
- Information
- 指摘にしない参考（「参考: 表示の速さ」「参考: 費用について」）。番号は振らない
重要度は、起きたときの結果と起きる条件から付けた分類で、直す順番や時期を決めたものではない。直すか、いつ直すかは、貴社の状況（公開の予定、関わる方、予算など）に合わせてお決めいただく。未確認の指摘は、確かめた結果、問題があった場合の重要度。重要度は、依存関係のスキャンの区分（CVSS）と同じ言葉を使っている。CVSS は部品の脆弱性そのものの深刻度、重要度はこのシステムでどの結果に届くかを確かめた範囲で付けたもの。両方を比べて、このシステムでの重要さを判断できる。
調べ方の見方
品質特性と、この診断の観点（ISO/IEC 25010）
ソフトウェアの品質を9つの特性で表す国際規格 ISO/IEC 25010:2023 に照らして、この診断の観点がどの特性を見ているかを示す。規格に沿った評価や、準拠を確かめたものではない。
| 品質特性 | この診断の観点 |
|---|---|
| 機能適合性（Functional suitability） | お金とデータの扱いで、食い違いが起きないか（お金と記録の食い違いに関わるところだけを見る。機能が仕様どおりに動くかの全体の試験はしない） |
| 性能効率性（Performance efficiency） | 利用が増えても、待たされずに使えるか |
| 互換性（Compatibility） | 今回の診断では見ていない |
| インタラクション能力（Interaction capability） | 今回の診断では見ていない |
| 信頼性（Reliability） | 止まったとき・壊れたときに、気づけて戻せるか／お金とデータの扱いで、食い違いが起きないか |
| セキュリティ（Security） | 外から不正に使われないか／持たなくてよいデータを、持っていないか |
| 保守性（Maintainability） | 担当が変わっても、安全に直し続けられるか |
| 柔軟性（Flexibility） | 今回の診断では見ていない |
| 安全性（Safety） | 今回の診断では見ていない |
外からの攻撃を見る観点
OWASP ASVS 5.0.0（Web アプリケーションの安全性を確かめる項目を、非営利団体 OWASP がまとめたもの）の L2（253件）を、外部からの攻撃を見る観点として参照した。ASVS への準拠を確かめたもの・認証したものではない。
ASVS の項目ごとの判定: 満たす 128件・満たさない 41件・該当しない 62件・未確認 22件。件数は ASVS の項目の数で、指摘の件数ではない。該当しないは、使っていない機能に当たる項目。指摘に関わる項目の番号は、第2部の各指摘に載せた。
ソースコードの品質を見る観点
ISO/IEC 5055:2021（ソースコードの品質を、信頼性・性能効率・保守性・セキュリティの特性ごとの弱点で表す国際規格）のもとになった、CISQ の品質の測定の弱点の一覧（CWE 4.20 の CWE-1305）を、観点を調べるときの見る目として参照した。規格に沿った測定や、準拠を確かめたものではない。指摘に関わる弱点の番号は、第2部の各指摘に載せた。
今回の範囲に含めなかったこと
- 網羅的な侵入テスト、修正作業
- 負荷試験・サーバーの性能の測定（表示の速さは、合意したページで Core Web Vitals の指標を測るだけ）
- ソースコードの品質の測定・点数付け（規格に沿った測定や、準拠の確認）
- スキャンで見つかった脆弱性の具体的な修正方針の検討と、修正したあとの動作確認
- 費用の見積もり
- 本番環境に対して攻撃を試すこと
- 公開してよいかの可否の判定
用語の説明
第2部修正のための資料 修正を担当する開発者の方向け
指摘の番号は第1部と共通。修正の方法と直したあとの動作確認は今回の範囲外。「直したあとに満たすべき状態」は、修正を担当する方が確かめるときの目安として書いている。
8. 指摘の一覧
| 番号 | 状態 | 指摘 | 重要度 | 詳細 |
|---|---|---|---|---|
| 指摘1 | 要対応 | 本番の決済とメール送信の鍵と、署名用の秘密が、ソースコードの中にそのまま書かれている | Critical | — |
| 指摘2 | 未確認 | 管理画面に入れる人の範囲が分からない | 問題があった場合Critical | — |
| 指摘3 | 要対応 | 申込の詳細画面で、URLの番号を変えると、別の会員の申込内容が見られる | High | 詳細へ |
| 指摘4 | 要対応 | 決済が終わったあとの処理で失敗すると、請求されたのに契約の記録が残らないおそれがある | High | — |
| 指摘5 | 要対応 | 申込のボタンの押し直しや決済完了の画面の開き直しで、同じ申込の決済や契約が重ねて作られる | High | 詳細へ |
| 指摘6 | 要対応 | ログインの状態を扱うライブラリに、深刻度が High の既知の脆弱性がある | High | — |
| 指摘7 | 要対応 | 本番用の設定に試験用の決済のキーが入ったままになっている | High | — |
| 指摘8 | 要対応 | 管理画面はメールアドレスとパスワードだけで入れ、ログインの試行の回数も制限していない | Medium | — |
| 指摘9 | 要対応 | 問い合わせフォームに入力した値が、確認画面でスクリプトとして動く | Medium | — |
| 指摘10 | 要対応 | 決済の失敗を社内に知らせる仕組みが見つからず、ログも3日で消える | Medium | — |
| 指摘11 | 要対応 | 契約の状態（申込中・有効・解約）を変える処理が4か所に分かれていて、自動テストがない | Medium | — |
| 指摘12 | 要対応 | 管理画面の申込の一覧で、申込1件ごとに会員の情報を問い合わせていて、取得する件数にも上限がない | Medium | 詳細へ |
| 指摘13 | 要対応 | ログアウトしてもサーバー側でログインの状態を切れず、ログインの状態に期限もない | Medium | — |
| 指摘14 | 要対応 | AWS の最上位の利用者に、二要素認証が設定されていない | Medium | — |
| 指摘15 | 要対応 | 本番にデプロイする権限を、どのブランチの処理からでも受け取れる | Medium | — |
| 指摘16 | 未確認 | バックアップから戻せるかが分からない | 問題があった場合Medium | — |
| 指摘17 | 未確認 | エラー監視サービスの通知を受け取る人と設定が分からない | 問題があった場合Medium | — |
| 指摘18 | 要対応 | 深刻度が Medium の既知の脆弱性があるライブラリが2件ある | Low | — |
| 指摘19 | 要対応 | 解約した会員の本人確認書類を消す仕組みがない | Low | — |
| 指摘20 | 要対応 | 管理画面で、誰がいつ何を操作したかを記録していない | Low | — |
| 指摘21 | 要対応 | データベースの保存時の暗号化が設定されていない | Low | — |
| 指摘22 | 要対応 | 申込の処理が約1,800行の1つのファイルにまとまっていて、決済・契約・メールの処理が入り組んでいる | Low | — |
| 指摘23 | 問題なし | HTTPSとセキュリティに関わるヘッダーが設定されている | 詳細へ | |
| 指摘24 | 問題なし | カード番号を、このシステムが受け取らない作りになっている | 詳細へ | |
| 指摘25 | 問題なし | データベースへの問い合わせに、入力値をそのまま埋め込んでいない | 詳細へ | |
| 指摘26 | 問題なし | 請求額を、利用者が送る値で決めていない | — | |
| 指摘27 | 問題なし | データベースに、インターネットから直接届く設定はない | — | |
| 指摘28 | 問題なし | ファイルの置き場所が、公開の設定になっていない | — |
9. 対象の技術情報と、ツールでの確認
依存関係のスキャン
| 深刻度（CVSS） | 対象 | このシステムでの使われ方 | 報告書での扱い |
|---|---|---|---|
| High・1件 | ログインの状態を扱うライブラリ | ログインと、ログイン中の会員の確認で動く。脆弱性が起きる条件に当てはまる設定で使っている | 指摘6（High）。脆弱性が起きる設定で使っているため、指摘にした |
| Medium・2件 | 通信と文字列の処理のライブラリ | 本番の全画面で動く。脆弱性が起きる処理を使っているかは、コードで確かめていない | 指摘18（Low）。起きる道筋を確かめていないため、CVSS より低く付けた |
| Low・1件 | 開発用の道具 | 本番では動かない | 本番では動かないため、指摘にしていない |
表の深刻度は CVSS の区分で、報告書の重要度とは別。スキャンで分かるのは、公開されている既知の脆弱性に限られる。見つかったものは、このシステムでの使われ方と照らし合わせて、指摘にするかと重要度を決めた。実際の報告書では、パッケージ名、今の版と修正された版、CVE番号、CVSSの値も書く。
試験環境に対する自動の確認
ツールの警告は、ソースコードと照らし合わせ、実害があるものだけを報告に残した。
10. 指摘の詳細（抜粋）
申込の詳細画面で、URLの番号を変えると、別の会員の申込内容が見られる
重要度: High 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か所だけだった。申込の番号はデータベースの連番。
- 起きる条件
- 会員としてログインし、自分のものではない申込の番号で詳細を開く。
- 業務への影響
- ログインしている会員なら誰でも、ほかの会員の氏名、住所、契約の内容を見られる。番号は連番なので、対象はすべての会員の申込に及ぶ。
- 直す場合に行うこと
- 申込の詳細を返す処理で、申込がログインしている会員のものかを確かめ、違う場合は表示しない。会員ごとのデータを番号で探すほかの処理にも、同じ確かめがあることを保つ。
- 直したあとに満たすべき状態
- ログインしている会員のものではない申込の番号を開くと、内容が返らないこと。自分の申込は、これまでどおり開けること。
申込のボタンの押し直しや決済完了の画面の開き直しで、同じ申込の決済や契約が重ねて作られる
重要度: High 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件だけ作られること。決済完了の画面を開き直しても、契約と領収のメールが1件のままであること。
管理画面の申込の一覧で、申込1件ごとに会員の情報を問い合わせていて、取得する件数にも上限がない
重要度: Medium CWE: CWE-1050 調べ方ソースコード・設定
- 該当箇所
src/app/admin/applications/page.tsx:18-46src/lib/db/applications.ts:30-52- コード上で起きていること
- 申込の一覧は、すべての申込を1回で取り出したあと、繰り返しの中で申込ごとに会員の情報をデータベースに問い合わせている。100件の申込を表示すると、問い合わせは101回になる。一覧の取得に、件数の上限やページ送りはない。
- 起きる条件
- 申込が増えたあとに、管理画面で申込の一覧を開く。
- 業務への影響
- 申込が増えるほど一覧の表示が遅くなり、ある時点から時間内に表示できなくなるおそれがある。件数と表示にかかる時間の関係は、今回は測っていない。
- 直す場合に行うこと
- 申込の一覧で、1回に取得する件数に上限を付け、会員の情報を申込1件ごとに問い合わせないようにする。
- 直したあとに満たすべき状態
- 申込の件数に関わらず、一覧の1回の表示で読み込む件数と、データベースへの問い合わせの回数が変わらないこと。
11. 問題なしと判断した確認の内容（抜粋）
HTTPSとセキュリティに関わるヘッダーが設定されている
試験環境の画面を読み込み、証明書、HTTPからHTTPSへの転送、セキュリティに関わる主なヘッダーを確かめた。本番環境のサーバーの設定とソースコードとも突き合わせ、公開後も同じ設定になることを確かめた。
カード番号を、このシステムが受け取らない作りになっている
カード番号の入力欄は、決済代行サービスが用意した部品の中にあり、入力されたカード番号は、このシステムのサーバーを通らない。試験環境で申込を行い、サーバーに届く内容とログに、カード番号が含まれないことを確かめた。
データベースへの問い合わせに、入力値をそのまま埋め込んでいない
検索や申込など、利用者が入力した値を使う問い合わせは、すべて値を文と分けて渡す書き方になっている。入力値をつなげて問い合わせの文を組み立てている箇所は見つからなかった。試験環境に対するツールでの自動の確認では、検索画面で1件、この問題を疑う反応が出た。手で再現して確かめたところ、入力の誤りを知らせる通常の画面で、問い合わせの文は組み立て直されていなかった。
このサンプルは、報告書の一部を抜き出して短くまとめたものです。報告書は、今回の方法と範囲で確かめた内容をまとめたもので、システムが安全であることを保証するものではありません。