Webサイト脆弱性の報告書と改善手順、危険度の高い順に直す方法
Webサイト脆弱性の報告書を受け取ったら、最初に危険度「高」の項目から手を付ける。
改善手順は、危険度の高い順に進めると被害が出る前に問題を減らせる。
報告書には問題ごとの直し方が並んでいる。
どこから着手するか、自社で直すか任せるかを決めるには、報告書の読み方を知っておく必要がある。
Webサイト脆弱性の報告書と改善手順、どこから読むか
Webサイト脆弱性の報告書を受け取ったら、最初に危険度「高」の項目を確認してほしい。
改善手順も、危険度の高い問題から進めるのが基本になる。
報告書の見方を間違えると、優先度の低い修正に時間を使い、危険な箇所を放置してしまう。
危険度の高、中、低が示す意味
危険度「高」は、攻撃が現実に通り、情報の流出やサイトの改ざんにつながる問題だ。
最初に直す。
危険度「中」は、特定の条件がそろうと危険な状態になる。
危険度「低」は、単独では大きな被害になりにくいが、別の弱点と組み合わさると危険になる場合がある。
報告書に書かれた問題を、そのまま置くとどうなるか
Webサイトの脆弱性を放置すると、情報の流出、サイトの改ざん、事業の停止といった事態が起きやすい。
客の個人情報や注文データが漏れれば、事業への信用が失われる。
報告書に載った問題は、危険度の高い順に直すのが安全だ。
報告書を受け取ってから、最初にやること
報告書を受け取ったら、最初に問題を再現できるか確かめる。
再現できれば、報告書の改善手順が今のサイトに合っていると判断できる。
再現できない場合は、条件が変わったか、報告の内容に食い違いがあるかを確認する。
報告内容が再現できるか確かめる
報告書に再現手順が書かれていたら、その通りに操作して問題が起きるか見る。
ログイン画面に問題があるなら、指摘された操作で本来見えない情報が出るかを試す。
再現には、本番とは別の確認用サイトを使うと安全だ。
本番のサイトで攻撃に近い操作をすると、負荷がかかったり、データを書き換えたままにしたりする。
影響のありそうなページと機能を名指しで確認する
報告書の問題ごとに、影響がどこまで及ぶかを確認する。
認証（ログインの仕組み）の不備なら会員情報や管理画面、通信の不備なら申し込みフォームや支払いの手続きが影響を受ける。
影響を受ける機能が分かれば、次の動作確認の範囲も狭められる。
改善手順を、サイトを止めずに進めるには
改善手順は、いきなり本番のWebサイト（実際に公開しているサイト）に適用しない。
まずテスト環境（本番と同じ構成の確認用サイト）を用意し、直した内容が動くかを確かめてから本番へ移す。
テスト環境があれば、サイトを止めずに修正を進められる。
本番の前に、テスト環境を用意する
テスト環境は、本番と同じ構成に近い場所を作る。
使っているWordPressやNext.js（JavaScriptのフレームワーク）の構成、サーバーの設定を揃えるほど、本番で起きる問題を先に見つけやすい。
社内にテスト環境が無ければ、開発担当者に相談するか、外部の技術者に環境の準備から頼む方法がある。
直した後の確認を、画面とログの両方で行う
修正をテスト環境に反映したら、画面の動きとサーバーのログを両方見る。
画面では、利用者の導線通りに動くか。
ログでは、意図しないエラーや不正なアクセスが残っていないかを確認する。
問題が消えていれば、本番環境へ反映する。
自社で直すか、修正まで任せるかを分ける
報告書の改善手順を自社で進めるか、外部に任せるかは、修正する範囲と社内の技術力で決める。
認証と認可（ログインと、ユーザーごとの権限の管理）、セッション（ログイン後の状態を覚えておく仕組み）のような外から見えない部分は、テストを整えないと直しにくい。
| 自社で直しやすいもの | 任せたほうがよいもの |
|---|---|
| 文言の修正 | 認証と認可の見直し |
| プラグインの更新 | セッション管理の修正 |
| 権限や公開範囲の変更 | APIと通信の見直し |
| 設定画面で完結する変更 | 依存パッケージの更新作業 |
自社で直せる範囲の見分け方
ユーザーの画面から見える文言の修正、プラグインの更新、ファイルの権限変更などは、手順が明確なら社内でも直しやすい。
認証と認可、セッションの扱い、API（外部のシステムとデータをやり取りする窓口）の設計は、動くことの確認に技術者が要るので、誰にでも直せる範囲ではない。
私たちに診断を依頼すると、どこまで進むか
私たちのウェブセキュリティ診断は、認証と認可、セッション、データの読み取り、APIと通信、依存パッケージ（サイトが使っている外部の部品）まで点検する。
見つかった問題は危険度の高、中、低に分け、問題ごとに具体的な改善手順を示した報告書を渡す。
報告で終わらせず、修正と対策の実施まで担当することもできる。
一般的なWebサイトに加えて、独自開発のシステムやNext.jsのモダンな構成も診断できる。
診断の前には、使用技術、サーバーとインフラの情報、これまでの事故の有無を確認する。
診断を依頼する前に確認しておくこと
Webサイトの脆弱性診断を依頼するときは、対象サイトの所有権または管理権限があることを確認してほしい。
サーバーやログインの情報は、正式な発注の後に共有する流れが安全だ。
所有権または管理権限のあるサイトだけが対象
私たちが診断するのは、依頼者本人に所有権または管理権限があるサイトに限る。
運営を委託されている場合も、管理権限があれば対象になる。
権限のないサイトは、診断すること自体が許可されていない操作になるため扱わない。
サーバーやログイン情報を渡すタイミング
サーバーやログインの情報は、正式な発注の後に共有してほしい。
見積もりや相談の段階では、対象のURLと使っている技術、気になっている箇所を聞かせてほしい。
情報の受け渡しを後にするのは、不要なログイン情報を渡す人を増やさないための手順だ。
よくある質問
報告書に載っている問題を、全部直す必要はあるか
危険度の高い順に直す。
危険度「高」と「中」は、ウェブサイトを公開しているなら早めに手を付ける。
危険度「低」は、直す手間と放置したときの影響を比べて、順番を決めればよい。
低と書かれていても、別の弱点と組み合わさるものは先に直すことがある。
自社で直す場合、どこから手を付ければよいか
報告書の改善手順を、危険度の高い順に1つずつ進める。
本番の前にテスト環境を用意し、再現の確認、修正、動作確認をその中で終わらせる。
テスト環境が無い場合は、作るか、外部の技術者に準備から頼むのが確実だ。
報告書の内容が分からない場合、どうするか
私たちの報告書は専門外の人にも分かる言葉で書く。
専門用語は、何が起きるかと、どう直すかという形で説明する。
読んで分からない箇所があれば、そのまま聞いてほしい。
独自開発のシステムやNext.jsのアプリでも診断できるか
診断できる。
一般的なWebサイトだけでなく、独自開発のシステム、Next.jsなどのモダンなWebアプリも対象にしている。
ソースコードを攻撃する側の視点で一行ずつ読み、プラグインに頼った点検では拾えない弱点まで洗い出す。
診断の結果、問題が無かった場合はどうなるか
問題が無ければ、その旨を報告書にまとめて渡す。
安心の根拠になる。
脆弱性はその後に見つかることもあるため、依存パッケージの更新や、設定の変更があったタイミングで再診断を受ける選択肢もある。
この記事のポイント
- Webサイト脆弱性の報告書は、危険度の高い順に読む
- 改善手順は、本番の前にテスト環境で試す
- 再現確認と影響範囲の切り分けを先に行う
- 自社で直せる範囲と、任せる範囲を分ける
- 診断は所有権または管理権限のあるサイトだけが対象
ウェブセキュリティ診断・対策認証から依存パッケージまで診断し、危険度と改善手順を報告書にまとめる。希望があれば修正まで担当するサービスの詳細を見る
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
セキュリティ診断は安くても大丈夫か。失敗しないために見る5つの点
セキュリティ診断を安さだけで選んでも大丈夫か。
答えは「安いこと自体が失敗の理由ではない」だ。
ただし、安い診断には調べる範囲が狭いことと、報告書だけで終わることが起きやすい。
この2つを見ておかないと、診断したのに穴が残ってしまう。
あなたが確かめたいのは、安いかどうかより、危険な場所から順に直せるところまで届くかどうかだ。
安い診断を選ぶときでも、中身と流れを確認すれば失敗は避けられる。
診断の失敗は、後から気づきやすい。
診断後に事故が起きて初めて「あの時、範囲を見ていなかった」と分かる。
そうならないための確認の仕方を、順を追って書く。
安いセキュリティ診断で起きる失敗
安い診断で起きる失敗は、大きく2つある。
調べる範囲が狭いことと、見つけた問題を直す手順まで手渡されないことだ。
どちらかが欠けると、診断を終えても「本当に安全か」を確かめられない。
自動ツールだけの点検で、見えない穴が残る
セキュリティ診断には、自動ツールだけのものと、人が攻撃する側の視点で調べるものがある。
自動ツールは、公開された脆弱性や設定のミスを素早く見つける。
一方で、認証やセッションの扱いのように、コードを一行ずつ読まないと分からない弱点は拾えない。
ログイン後に他の利用者の情報を見られてしまう欠陥も、このタイプだ。
安さの理由が「ツールだけ」である場合、表面は問題なしと出ても、深い場所に穴が残る。
報告書だけを受け取って止まる
診断結果が一覧で渡されても、何から直すかが分からなければ、報告書は棚に置かれたままになる。
危険度の高、中、低に分かれ、それぞれに具体的な直し方が付いていて、初めて手を付けられる。
自社に直す人員がいないなら、修正まで引き受けてくれるかも確認しておく。
| ありがちな形 | 確認したい形 |
| 自動ツールだけで表面を点検する | 認証やセッションまでコードを読んで点検する |
| 問題の一覧だけを渡す | 危険度の高・中・低と直し方を渡す |
| 報告書で終わる | 希望すれば修正まで進める |
安くても大丈夫かを見分けるチェック項目
安い診断だからといって、すべてが失敗につながるわけではない。
安くても、次の2つがそろっていれば判断材料としては十分に使える。
逆に、これが無いなら、安さの分だけ何かが省かれていることが疑わしい。
あなたのサイトの構成を診られるか
診断の範囲は、相手が普段診ている対象によって変わる。
一般的なWebサイト向けの点検では、独自に作ったシステムやNext.jsのようなモダンな構成の穴まで届かない。
診断前に、使用している技術、サーバーとインフラ、これまでに事故があったかを伝えられるかを見る。
あなたのサイトと同じ構成を診られるかも確認する。
危険度の順と直し方が付くか
報告書の中身が、後からの行動を決める。
見つかった問題が危険度の高、中、低に分かれて並び、それぞれにどう直すかが書かれているかを見る。
専門外の人が読んでも分かる言葉で書かれていると、社内で「どこから着手するか」を決めやすい。
見つけた箇所を並べただけの報告書では、優先順位が付かず、結局すべてが後回しになる。
診断の前後にやっておくこと
診断が失敗する原因には、前後の段取りもある。
用意する情報と、共有するタイミングを間違えると、診断が始まらないか、始まっても思った場所まで届かない。
順に整えておくと、安い診断でも大丈夫かを見極めやすくなる。
診断の前に用意する情報
診断を受ける前には、次の情報をまとめておく。
- 対象になるサイトのURL
- 使用している技術（言語、フレームワーク、ライブラリ）
- サーバーとインフラの情報
- これまでに事故があったかどうか
これらを先に整理しておくと、診断できる範囲とできない範囲がはっきりする。
サーバーやログイン情報は発注後に共有する
サーバーやログインの情報は、正式な発注が決まった後で共有すればよい。
見積もりの段階で機密情報を渡す必要はない。
診断する側も、発注前に詳しい情報を受け取るより、決まってから受け取る方が安全に扱える。
先に渡すように急かす相手には注意する。
私たちの場合も、サーバーやログイン情報は正式な発注の後に共有してもらっている。
診断後どこまで進むか
報告書を受け取った後にどうなるかを確認する。
自社で直せるなら、直し方の手順が具体的かを見る。
自社では直せないなら、修正と対策の実施までお願いできるかを確かめる。
報告書を受け取って終わりなのか、直すところまで進めるのかで、その後の安心感が変わる。
安さより中身で選ぶための考え方
セキュリティ診断を安さだけで選ぶと、後から「診たはずの場所が漏れていた」と気づく失敗につながる。
安いことが問題なのではなく、安さの理由を確認しないことが問題だ。
何が省かれているのかを知った上で選べば、安い診断でも失敗は避けられる。
あなたにとってのゴールは、診断を受けることではなく、危険な場所から順に手を打てる状態になることだ。
安さの裏で次の3つが消えていないかを確かめるのが、安い診断で失敗しないための最短の手順だ。
- 診断の範囲が自社の構成に合っている
- 危険度の順と直し方が報告書にある
- 必要なら修正まで進められる
私たちが診断をするときも、対象のサイトに所有権か管理権限があるかを先に確認し、サーバーやログイン情報は正式な発注後に共有してもらう。
安さで選ぶ前に、この流れを整えておくと、診断の失敗は避けられる。
よくある質問
安いセキュリティ診断でも、危険な場所は見つかりますか
自動ツールで見つかる公開された脆弱性や設定ミスは、安い診断でも見つかることがある。
ただし、認証やセッションのようにコードを読まないと分からない穴は、範囲に含まれていないと残る。
何を診るかを先に聞くと、見つかる範囲がはっきりする。
診断はWebサイトだけが対象ですか
一般的なWebサイトに加えて、独自開発のシステムやNext.jsのようなモダンなWebアプリを診られるかは、相手によって違う。
自社の構成を伝えて、対象になるかを確認する。
診断できるのは、依頼者本人に所有権または管理権限があるサイトに限られる。
サーバー情報はいつ渡せばよいですか
正式な発注の後で共有すればよい。
見積もりの段階でサーバーやログインの情報を渡す必要はない。
発注前に急かされたら、先に進む前に扱いを確認する。
報告書をもらった後、自社で直せない場合はどうすればよいですか
修正まで受け付けてくれる相手を選ぶ。
危険度の順と直し方が付いた報告書があれば、修正を外注する場合も、どの範囲から頼むかがはっきりする。
報告書だけで終わる相手と、修正まで進める相手の違いは、選ぶ段階で確認しておくと安心できる。
診断後に「問題なし」と言われました。信じても大丈夫ですか
「問題なし」は、何を診たかの裏付けがあって初めて信じられる。
自動ツールだけの点検なら、コードの内部に穴が残ったままだ。
診た範囲と方法が報告書に書かれているかを見ると、判断しやすい。
この記事のポイント
- 安い診断の失敗は、範囲が狭いことと報告書だけで終わること
- 安くても、対象の構成と危険度順の報告書があれば判断できる
- サーバーやログイン情報は正式な発注後に共有する
- 診断後、修正まで進めるかを確認すると安心できる
- 安さではなく、範囲と報告書と修正先の中身で選ぶ
ウェブセキュリティ診断・対策認証から依存パッケージまで診断し、危険度と改善手順を報告書にまとめる。希望があれば修正まで担当するサービスの詳細を見る・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験