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最適化の豊富な経験