Webセキュリティ診断ツールと現代的な検査方法

はじめに

WebサイトやWebシステムのセキュリティ確認では、脆弱性診断ツールを使った検査が有効です。

IPAが紹介しているような診断ツールは、Webサイトの基本的な安全性を確認する入口として役立ちます。

ただし、現在のWebシステムは、WordPress、クラウド、API、外部サービス連携、会員機能、予約フォーム、決済機能など、構成が複雑になっています。

そのため、現在の実務では、ひとつのツールだけに頼るのではなく、

本番環境への影響を抑えた確認
ステージング環境での詳細診断
ソースコードや依存ライブラリの確認
運用ルールや権限設定の確認

を組み合わせることが重要です。

1. IPAが紹介する診断ツールの位置づけ

IPAなどで紹介されている診断ツールは、Webサイトの基本的な脆弱性を確認するための有効な手段です。

代表的なものには、以下のようなツールがあります。

このような比較表は、診断ツールの特徴を理解するうえで参考になります。

ただし、現在の実務では、単に「どのツールが良いか」だけで判断するのではなく、

どの環境に対して、どの強度で、どこまで検査するかを考える必要があります。

2. ツール診断は「入口」として有効

OWASP ZAPのようなツールは、Webサイトの代表的な問題を確認するうえで非常に有効です。

例えば、以下のような項目を確認できます。

このような確認は、Webサイトの基本的な健康診断として有効です。

特に中小企業のWebサイトやWordPressサイトでは、まずこの段階の確認を行うだけでも、多くの問題を発見できることがあります。

3. ただし、自動診断だけでは見つけにくい問題もある

自動診断ツールは便利ですが、万能ではありません。

特に、以下のような問題はツールだけでは見落とされやすいです。

つまり、ツール診断は重要ですが、最終的には人間による確認も必要です。

4. 本番環境への影響を考える

Web診断で特に重要なのが、本番環境への影響です。

診断ツールの使い方によっては、実際のWebサイトに負荷をかけたり、フォームに大量のテストデータを送信したり、サーバー側の防御機能にブロックされることがあります。

本番環境で起こり得る影響

そのため、本番環境では強い攻撃系診断を行うのではなく、影響の少ない診断にとどめるのが基本です。

5. 本番環境とステージング環境を分ける

現代的なWeb診断では、環境を分けて考えることが大切です。

重要なのは、
本番で何でも検査するのではなく、検査内容に応じて環境を分けること
です。

6. 現代的なWeb診断の全体像

現在のWebセキュリティ診断では、以下のように複数の診断方法を組み合わせるのが実務的です。

このように見ると、Webセキュリティ診断は単なるツール実行ではなく、技術・設定・運用を含めた総合確認
であることがわかります。

7. 中小企業向けの現実的な診断方法

中小企業や小規模事業者のWebサイトでは、いきなり高額な本格診断を行うよりも、まずは現実的な範囲で確認することが重要です。

中小企業向けWeb診断の基本ステップ

この流れであれば、本番環境への影響を抑えながら、現実的なセキュリティ確認ができます。

8. WordPressサイトで特に確認すべき項目

中小企業のWebサイトでは、WordPressが使われているケースが多いため、以下の確認が重要です。

WordPressの場合、ツール診断だけでなく、管理画面やプラグイン設定の確認が非常に重要です。

9. 診断ツールの正しい使い方

診断ツールは、使い方を間違えると危険です。

大切なのは、ツールを使う前に以下を明確にすることです。

診断ツールは、
許可された範囲で、影響を考慮して使うもの
です。

10. 講義で伝えたい重要ポイント

Webセキュリティ診断では、以下の考え方が重要です。

ポイント1

IPAの診断方法は基本を学ぶ入口として有効

IPAの資料やツール紹介は、Webセキュリティ診断を理解するうえで有効です。
まずは基本的な考え方を学ぶことが大切です。

ポイント2

自動診断ツールは万能ではない

ツールは多くの問題を見つけることができますが、権限設定や業務ロジックの問題は見落とされることがあります。

ポイント3

本番環境への影響を考える

攻撃に近い検査を本番環境で行うと、フォーム送信、ログ汚染、サーバー負荷、アカウントロックなどの影響が出る可能性があります。

ポイント4

本番とステージングを分ける

本番では軽量診断、ステージングでは詳細診断を行うのが安全です。

ポイント5

ツール・設定・運用を組み合わせる

Webサイトの安全性は、ツール診断だけではなく、更新管理、権限管理、バックアップ、ログ確認などの運用面も重要です。

11. まとめ

Webセキュリティ診断では、IPAが紹介するようなツールや検査方法は、基本を理解するうえで有効です。

しかし、現在のWebサイトは複雑化しており、ひとつのツールだけで安全性を判断することはできません。

大切なのは、

本番環境では影響の少ない確認を行うこと
攻撃系の検査はステージング環境で行うこと
ソースコードや依存ライブラリも確認すること
WordPressや管理画面の運用状態も確認すること
最終的には人間の目で権限や業務ロジックを確認すること

です。

つまり、現代のWebセキュリティ診断は、

ツールを使う診断から、環境・運用・設計を含めた総合的な診断へ

変わってきています。

追加章：LAMP環境のバージョンが古いサイトの危険性

1. 脆弱性診断以前に「土台」が古いサイトがある

Webサイトのセキュリティ診断というと、OWASP ZAPなどのツールを使った検査をイメージしがちです。

しかし、実際の現場では、診断ツール以前の問題として、

Apache
PHP
MySQL / MariaDB
Linux OS
WordPress本体・テーマ・プラグイン

などの基本的なバージョンが、かなり古いまま放置されているサイトも多く見受けられます。

このような状態は、いわば

家のドアや窓を点検する前に、建物の土台が古くなっている状態

です。

フォームの安全性やセキュリティヘッダーを確認することも大切ですが、その前に、Webサイトを動かしている基盤ソフトウェアがサポート対象かどうかを確認する必要があります。

2. LAMPとは何か

LAMPとは、WebサイトやWebシステムを動かす代表的な構成のことです。

WordPressサイトの場合、このLAMP構成の上で動いていることが多いです。

つまり、WordPress本体やプラグインだけを更新していても、PHPやApacheが古ければリスクは残るということです。

3. サポート切れバージョンは何が危険なのか

3-1. セキュリティ修正が受けられない

PHP公式では、各リリースブランチは初回安定版リリースから一定期間、バグ修正やセキュリティ修正を受けると説明されています。逆に、サポート対象外になった古いリリースは公式にはサポートされません。

サポートが切れたバージョンを使い続けるということは、

新しい脆弱性が見つかっても、公式の修正が提供されない状態

になるということです。

これは非常に危険です。

3-2. 攻撃者にとって狙いやすい

古いApacheやPHPには、過去に公開された脆弱性情報が多数存在します。

Apache HTTP Server公式の脆弱性情報ページでは、各バージョンで修正された脆弱性や、影響を受けるバージョンが公開されています。たとえばApache 2.4系でも、情報漏えい、DoS、リクエストスマグリング、パストラバーサル、リモートコード実行など、さまざまな脆弱性が過去に修正されています。

脆弱性情報が公開されると、攻撃者はその情報をもとに自動スキャンを行います。

つまり、

古いバージョンを使っているだけで、攻撃対象として見つけられやすくなる

ということです。

3-3. WordPressやプラグインの更新にも影響する

PHPが古いと、WordPress本体、テーマ、プラグインの更新にも支障が出ます。

WordPress公式の開発者向け情報では、2026年5月時点で、WordPressの推奨PHPバージョンは8.3とされています。

PHPが古いままだと、

という問題が起きます。

つまり、PHPの古さは単なる技術的な問題ではなく、Webサイト全体の保守性と安全性の問題です。

4. 古いバージョンで起こり得るリスク

特に中小企業のサイトでは、見た目が普通に表示されているため、問題に気づきにくいです。

しかし実際には、

表示されていることと、安全であることは別

です。

5. よくある危険な状態

例1：PHP 7.4以前を使い続けている

PHP 7系のまま放置されているサイトは、今でも見かけます。

「今のところ表示されているから大丈夫」と思われがちですが、これは危険です。

PHPが古いと、WordPressやプラグインの更新が止まり、結果としてサイト全体が古くなっていきます。

例2：Apacheのバージョンが古い

Apache 2.4系でも、古いマイナーバージョンには過去の脆弱性が残っている可能性があります。

Apache公式は、Apache HTTP Server 2.4の脆弱性情報として、修正済みの脆弱性と影響バージョンを公開しています。
また、JVNでもApache HTTP Server 2.4系の複数脆弱性に対応したアップデート情報が公開されています。

例3：OS自体がサポート切れ

Linux OSがサポート切れの場合、ApacheやPHPだけ更新しても不十分です。

OSのセキュリティ更新が止まっていると、カーネル、OpenSSL、SSH、各種ライブラリにも問題が残る可能性があります。

例4：レンタルサーバーで古いPHPを選んだまま

レンタルサーバーでは、管理画面からPHPバージョンを切り替えられることがあります。

しかし、過去に作ったサイトが古いPHPのまま残っているケースがあります。

特に、

PHP 5系
PHP 7.0 / 7.1 / 7.2 / 7.3 / 7.4
古いPHP 8.0 / 8.1

などは注意が必要です。

6. ただし「バージョン番号だけ」で即断しない

ここは講義で大事です。

サーバーによっては、見た目のバージョン番号が古くても、OSベンダーがセキュリティ修正をバックポートしている場合があります。

例えば、Linuxディストリビューションでは、上流ソフトウェアの最新版番号には上げず、古い番号のままセキュリティ修正だけを取り込むことがあります。

そのため、外部診断ツールで

Apache 2.4.XXだから古い
PHP 8.Xだから古い

と表示されても、必ずしも即危険とは限りません。

ただし、確認すべきポイントは明確です。

講義ではこう言うと正確です。

バージョン番号が古く見えるから即アウト、ではありません。
しかし、サポート切れOS、サポート切れPHP、更新されていないApacheを使っている場合は、明確なリスクです。
大切なのは、バージョン番号だけではなく、サポート対象か、セキュリティ更新が適用されているかを見ることです。

7. バージョン確認方法

7-1. SSHで確認する方法

サーバーにSSHで入れる場合は、以下のコマンドで確認できます。

OS確認

cat /etc/os-release

または、

lsb_release -a

確認するポイントは、

Apache確認

Ubuntu / Debian系では、

apache2 -v

または、

apachectl -v

CentOS / AlmaLinux / Rocky Linux系では、

httpd -v

パッケージ情報まで見る場合は、

dpkg -l | grep apache2

または、

rpm -qa | grep httpd

PHP確認

php -v

PHP-FPMを使っている場合は、

php-fpm -v

PHPの設定情報を確認する場合は、

php -i | grep "PHP Version"

読み込んでいる設定ファイルを確認する場合は、

php --ini

MySQL / MariaDB確認

mysql --version

または、

mariadb --version

DBにログインできる場合は、

SELECT VERSION();

8. WordPress管理画面で確認する方法

WordPressの場合、管理画面からも確認できます。

確認場所

管理画面 → ツール → サイトヘルス → 情報 → サーバー

ここで以下を確認できます。

WordPress案件では、まずこの画面を見るだけでもかなり有効です。

9. レンタルサーバー管理画面で確認する方法

Xserver、XREA、さくら、ConoHa、ロリポップなどのレンタルサーバーでは、管理画面にPHPバージョン設定があります。

確認する場所の例です。

特に重要なのは、

ドメインごとにPHPバージョンが違う場合がある

という点です。

同じサーバー内でも、AサイトはPHP 8.3、BサイトはPHP 7.4ということがあります。

10. 外部から確認する方法

外部からも、ある程度は確認できます。

HTTPヘッダー確認

curl -I https://example.com/

見る項目の例です。

Server: Apache
X-Powered-By: PHP/7.4.33

ただし、これは注意が必要です。

つまり、外部から見えないから安全というわけではありません。

逆に、外部からPHPやApacheの詳細バージョンが見えている場合は、情報公開を減らす設定も検討すべきです。

11. phpinfoは便利だが公開禁止

PHPの詳細確認で phpinfo() を使うことがあります。

<?php
phpinfo();

これは確認には便利ですが、公開サイト上に置いたままにしてはいけません。

phpinfo() には、以下のような情報が表示されます。

使う場合は、確認後すぐ削除します。

講義ではこう伝えるとよいです。

phpinfoは健康診断のためのレントゲン写真のようなものです。
便利ですが、外に貼り出してはいけません。

12. 確認すべき基準

PHP

PHP公式では、サポート対象バージョンと、過去のサポート終了リリースが公開されています。

Apache

Apacheは単純にバージョン番号だけではなく、OSベンダーのバックポート状況も含めて確認します。

OS

WordPress

13. 改善の進め方

古いLAMP環境を見つけた場合、いきなり本番でPHPを上げるのは危険です。

以下の順番で進めます。

安全な更新手順

14. 受講者に伝えるべき実務ポイント

ポイント1

見えているサイトが安全とは限らない

Webサイトは、画面が普通に表示されていても、裏側のPHPやApacheが古いことがあります。

ポイント2

サポート切れは「今すぐ壊れる」ではなく「守られない」

サポート切れの危険性は、今日すぐサイトが止まることではありません。

問題は、

脆弱性が見つかっても修正されないこと

です。

ポイント3

古いPHPはWordPress更新の足かせになる

PHPが古いと、WordPress本体やプラグインの更新ができなくなります。

結果として、サイト全体が古くなり、脆弱性が積み重なります。

ポイント4

バージョン番号だけで判断しない

Linuxでは、古い番号のままセキュリティ修正だけが適用されることがあります。

そのため、

バージョン番号
OSのサポート状況
パッケージ更新状況
ベンダーの保守状況

をセットで確認します。

ポイント5

更新は必ずバックアップと検証環境で行う

PHPやApacheの更新は、サイトの動作に影響することがあります。

特にWordPressでは、古いテーマやプラグインが新しいPHPに対応していない場合があります。

そのため、いきなり本番で更新するのではなく、ステージング環境で確認してから本番に反映します。

15. まとめ

Webセキュリティ診断では、OWASP ZAPなどの診断ツールを使うことも大切です。

しかし、それ以前に確認すべきことがあります。

それが、

Apacheのバージョン
PHPのバージョン
MySQL / MariaDBのバージョン
Linux OSのサポート状況
WordPress本体・テーマ・プラグインの更新状況

です。

これらが古いまま放置されていると、診断ツールで表面的な問題を確認しても、根本的なリスクは残ります。

Webサイトのセキュリティは、見た目だけでは判断できません。

表示されているサイトの裏側では、Apache、PHP、MySQL、Linux、WordPressなど、さまざまなソフトウェアが動いています。

これらのバージョンが古く、サポートが切れている場合、脆弱性が見つかっても修正されず、攻撃者に狙われやすい状態になります。

セキュリティ診断では、フォームや画面の検査だけでなく、まずは土台となるLAMP環境がサポート対象か、更新されているかを確認することが重要です。

つまり、Webセキュリティの第一歩は、
サイトが表示されるかではなく、安全に維持できる状態かを見ること
です。