# PHP製Webサイトの脆弱性を狙った攻撃を防ぐ｜必要な対策5つと、当社が受け付ける対応の進め方｜株式会社テクノスフィア > PHP製Webサイトはサポート終了（EOL）のPHP、古いCMSプラグイン、実装の穴、置き忘れた設定ファイルの4か所から攻撃されます。当社が自社の検証環境を棚卸しして見つけた実態と、その是正の経験をもとに、棚卸し・更新・設定強化・実装点検・監視の5つの対策と、診断から継続監視まで当社が受け付ける対応の進め方を解説します。 URL: https://technosphere.co.jp/blog/php-website-vulnerability-protection ** 目次 1. PHP製サイトが狙われ続ける理由 2. 穴は4か所にある 3. 必要な対策は5つ 4. 当社の社内棚卸しでわかったこと 5. 当社が受け付ける対応の進め方 6. よくある質問（FAQ） 7. まとめ ** 本記事について 本記事は、当社が2026年10月に社内のWebサーバーを棚卸しし、PHPの稼働環境と既知の脆弱性を調査した記録をもとにしています。記事中のサイト名・環境名は**すべて伏せるか架空のものに置き換えています**。攻撃の手口は、防御のために一般に知られている範囲で紹介します。 ## PHP製サイトが狙われ続ける理由 会社案内のサイト、問い合わせフォーム、WordPress で作ったブログ、受注管理の画面——世の中のWebサイトの多くは PHP で動いています。サーバー側の言語としてもっとも広く使われているぶん、**攻撃のツールも PHP 向けがもっとも充実しています**。攻撃者は相手を選びません。インターネット上のサーバーを機械的に巡回し、「古いPHPか」「よく知られた脆弱性のあるプラグインが入っているか」「設定ファイルが置き忘れられていないか」を試して回ります。 厄介なのは、PHP製サイトは**作った時点では安全でも、時間とともに危なくなる**ことです。PHP 本体には[サポート期限](https://www.php.net/supported-versions.php)があり、期限を過ぎると新しく見つかった脆弱性が修正されなくなります。2026年10月の時点で、PHP 7.4・8.0・8.1 はすでにサポート終了、PHP 8.2 も2026年12月31日で終了します。WordPress のプラグインや、メール送信・PDF 生成に使うライブラリも同様に、更新を止めた瞬間から古くなっていきます。 IPA（情報処理推進機構）の「[情報セキュリティ10大脅威 2026](https://www.ipa.go.jp/security/10threats/10threats2026.html)」でも、組織向けの脅威として「システムの脆弱性を悪用した攻撃」が4位に挙がっています。本記事では、PHP製サイトのどこに穴ができるのか、何をすれば塞げるのか、そして当社がどう対応するのかを順に説明します。 ## 穴は4か所にある （図: 青いWebサーバーの建物の壁に空いた4つの穴から古い歯車・錆びたプラグ・ひび割れたブロック・開いた引き出しが覗き、オレンジ色の虫が集まる中、白いロボットが懐中電灯で点検しているイメージイラスト） 「PHPの脆弱性」と一口に言っても、穴が空く場所は1つではありません。当社では、PHP製サイトの穴を次の4か所に分けて考えています。対策が違うので、分けて見ることが大切です。 | 穴の場所 | 具体例 | 何が起きるか | | **1. PHP本体** | サポート終了（EOL）の PHP 7.4・8.0・8.1。古い Apache・nginx | 公開済みの脆弱性がそのまま残り、既知の手口で侵入される | | **2. CMS・プラグイン・ライブラリ** | WordPress 本体と更新が止まったプラグイン、古いメール送信・PDF生成ライブラリ、古い jQuery | プラグインの脆弱性からファイルの書き換え、Webシェルの設置へ進む | | **3. 自作部分の実装** | SQL文への文字列連結、エスケープ漏れ、ファイル名の直接指定、アップロードの検査漏れ、権限確認の漏れ | SQLインジェクション・XSS・パストラバーサルで、データの読み出しや画面の改ざん | | **4. 設定と置き忘れ** | エラー表示が有効、PHPのバージョンをヘッダーで公開、公開領域に残った phpinfo・テスト用ファイル・バックアップ・SQLダンプ | 内部構造やパスワードが読まれ、次の攻撃の足がかりになる | 3の「実装」は、作った会社の技量に左右される部分です。一方、1・2・4は**きちんと作られたサイトでも、運用の中で自然に発生します**。PHP のサポートは切れ、プラグインは更新を止め、作業の途中で置いたファイルは忘れられます。そして攻撃ツールが最初に試すのは、まさにこの1・2・4です。代表的な攻撃手法とログに残る痕跡は、[別の記事](https://technosphere.co.jp/blog/web-attack-techniques-log-detection)で10種類を整理しています。 ## 必要な対策は5つ （図: 白いロボットが支える青い盾の周りを、虫眼鏡・上向き矢印・南京錠・設計図・レーダーの5つのアイコンが円環状に囲み、外からの矢を跳ね返しているイメージイラスト） 4か所の穴に対して、当社が必要だと考える対策は次の5つです。どれか1つで済む話ではなく、上から順に積み上げるものです。 ### 対策1. 棚卸し——どこで、どのPHPが動いているかを知る 意外に思われるかもしれませんが、最初の壁はここです。「このサイトの PHP は何系ですか」と聞かれて即答できる会社は多くありません。制作会社に任せたまま、サーバーを借り換えたまま、担当者が代わったまま、という状態がふつうです。公開中のドメインごとに、**どのサーバーで・どのPHPバージョンで・どのCMSとプラグインが・どのライブラリとともに**動いているかを一覧にします。使っていないのに残っているサイトや、ドメインが消えたのに残っている転送設定も、このとき見つかります。 ### 対策2. 更新——PHP本体・CMS・ライブラリをサポート内に保つ サポート終了の PHP は、サポート中のバージョン（2026年10月時点では 8.3 以降が望ましい）へ更新します。WordPress は本体とプラグインを最新にし、**使っていないプラグインは「無効化」ではなく削除**します。無効化してもファイルは Web から到達できる場所に残るためです。メール送信や PDF 生成のライブラリも、同梱されたまま何年も更新されていないことが多いので、バージョンを確認して入れ替えます。 ### 対策3. 設定の強化——攻撃者に情報を渡さない 公式の PHP には、本番向けの設定の雛形（`php.ini-production`）が同梱されていますが、Docker の公式イメージなどでは**設定ファイルを置かない限り開発向けの既定値**で動きます。本番で最低限そろえたい設定は次のとおりです。 - **エラー表示を止める**——`display_errors=Off`。エラー画面には、ファイルの場所や SQL 文などの内部情報が含まれます - **バージョンを隠す**——`expose_php=Off`。応答ヘッダーの `X-Powered-By` で PHP のバージョンを名乗らないようにします - **外部ファイルの読み込みを禁止**——`allow_url_include=Off`。外部 URL のプログラムを読み込ませる攻撃を根元で防ぎます - **Cookie を守る**——`session.cookie_httponly=1`・`session.cookie_secure=1`。XSS や盗聴でログイン状態を盗まれにくくします - **公開領域を掃除する**——phpinfo の呼び出し、テスト用ファイル、`.git`・`.env`・バックアップ・SQL ダンプを公開領域から取り除きます。アップロード先では PHP を実行させません ### 対策4. 実装の点検——自作部分の典型的な穴を塞ぐ 自作の PHP には、SQL 文をプレースホルダで組み立てているか、画面に出す値をエスケープしているか、ファイル名やIDを利用者から直接受け取っていないか、アップロードされたファイルの種類を検査しているか、**表示のたびに「その人が見てよいデータか」を確認しているか**、という定番の確認項目があります。IPA の「[安全なウェブサイトの作り方](https://www.ipa.go.jp/security/vuln/websecurity/about.html)」に沿って点検し、見つかった箇所を直します。 ### 対策5. 監視——すり抜けた攻撃に気づく 対策1〜4は「防ぐ」ための対策です。ただし、更新の合間に新しい脆弱性が公開されることもあれば、点検で見落とした箇所が残ることもあります。**防御には必ずどこかに穴が残る**前提で、ログを見て攻撃の試行と成功の兆候を見分け、被害が広がる前に気づく仕組みを最後に置きます。 | 対策 | 主に塞ぐ穴 | 一度やれば終わりか | | **1. 棚卸し** | すべての前提 | サイトの追加・廃止のたびに更新 | | **2. 更新** | 1. PHP本体 / 2. CMS・ライブラリ | サポート期限ごとに繰り返す | | **3. 設定の強化** | 4. 設定と置き忘れ | 一度整えれば、環境の作り直し時に再確認 | | **4. 実装の点検** | 3. 自作部分の実装 | 機能追加のたびに対象を点検 | | **5. 監視** | すり抜けたすべて | 継続 | ## 当社の社内棚卸しでわかったこと （図: 白いロボットがクリップボードを手に、棚に並んだ多数の小さなサーバーボックスを1つずつ点検し、ひびの入った古いボックスにオレンジ色のマークが付いているイメージイラスト） 対策を人に勧める前に、まず自分たちの足元を見ました。当社は顧客向けの検証環境や社内ツールを多数のコンテナで運用しています。2026年10月、それらを対象に**読み取りだけの棚卸し**を行いました。各コンテナの中で PHP の設定値を読み、同梱ライブラリと WordPress プラグインのバージョンを集め、公開領域に危険なファイルが無いかを探す、という手順です。設定の変更や攻撃を模したアクセスは一切していません。 結果は、セキュリティを事業として掲げる会社として、率直に言って恥ずかしいものでした。4か所の穴のうち「実装」を除く3か所が、当社の足元にもそのまま存在していました。 - **サポート終了の PHP**——複数の検証環境が、サポートの切れた PHP で動いていました。そのうち1環境は、顧客確認用の検証サイトとして**インターネットに公開されたまま**でした - **開発向けの既定値のままの設定**——エラー表示が有効、PHP のバージョンを応答ヘッダーで公開。本番向けの設定ファイルを置く運用そのものが標準化されていませんでした - **公開領域の置き忘れ**——phpinfo だけを呼ぶファイル、テスト用のスクリプト、移行時のデータベースダンプや圧縮ファイルが、ドキュメントルートに残っていました - **「無効化」したつもりのプラグインと古いライブラリ**——名前を変えて無効化したつもりのプラグインの複製や、移行ツールのバックアップが Web から到達できる場所に残り、サポートの切れたメール送信・PDF 生成ライブラリや古い jQuery が同梱されていました - **消し忘れの転送設定**——廃止したドメインへのリバースプロキシの転送ルールが残っており、誤って DNS を再登録すると、意図しない社内ツールが外部に公開される状態でした どれも「動いているから大丈夫」と思っていた環境です。検証環境の大半は社内ネットワークからしか届きませんが、**公開中の環境が1つでもあった以上、「社内だけだから」とは言えません**。見つかった個々の穴より重いのは、本番向けの設定を全環境に当てる運用が無かったことでした。 ### 見つけたあと、どうしたか 棚卸しの結果は、そのまま是正の作業一覧にしました。 - **公開中だった環境**——外部から到達できない状態にし（2026年10月）、転送設定そのものの削除を進めています。この環境の PHP は本番と版を揃えているため、更新は本番側の更新提案と一緒に計画します - **消し忘れの転送設定**——残っていたルールの削除と、残す全ルールへのアクセス制限の設定を進めています - **サポート終了の PHP**——各環境を「更新」「廃止」に振り分け、顧客案件の検証環境は各保守案件と調整しながら 8.3 系へ更新しています。**検証環境と本番が同じコードで動いているなら、本番にも同じ穴がある**可能性が高いため、本番側の確認も各保守案件で進めています - **設定の標準化**——本番向けの設定ファイルを1か所で管理し、すべての PHP コンテナがそれを読む構成に揃えています。是正後に同じ手順で再点検し、指摘が 0 件になったことを確認して完了とします この棚卸しと是正の手順、確認項目を、そのままお客様向けの診断に使っています。是正が終わった時点で、何を直してどう確認したかを続編として公開する予定です。 ## 当社が受け付ける対応の進め方 （図: 虫眼鏡・天秤・工具箱・レーダーの4つの島が光の橋で一列につながり、白いロボットが旗を持って橋を渡っているイメージイラスト） 当社では、PHP製Webサイトの脆弱性対策を、診断から継続監視までの一連の作業として受け付けています。自社で制作したサイトに限らず、**他社が制作したサイト、WordPress のサイト、担当者が代わって中身がわからなくなったサイト**も対象です。進め方は次の4段階です。 ### 段階1. 現状診断（読み取りのみ・サイトは止めない） 社内の棚卸しと同じ手順で、PHP とミドルウェアのバージョン、設定値、CMS・プラグイン・ライブラリのバージョン、公開領域の危険なファイルの有無を確認します。設定の変更や、攻撃を模した大量アクセスは行いません。結果は**高・中・低の3段階に分けた指摘事項と対応案**として報告します。「公開中かどうか」と「サポート終了かどうか」の組み合わせで優先度を決めるので、何から手を付けるべきかが明確になります。 ### 段階2. 優先順位と暫定策 もっとも急ぐのは「インターネットに公開中で、サポート終了の PHP」です。更新には検証の時間がかかるため、まず**アクセス制限（IP 制限や BASIC 認証）で攻撃面を減らす暫定策**を先に入れ、そのうえで更新の計画を立てます。消し忘れのファイルや転送設定の削除も、この段階で済ませます。 ### 段階3. 更新・設定強化・実装修正 PHP 本体の更新は、本番と同じ構成の検証環境で先に行い、エラーの洗い出し・修正・動作確認を済ませてから本番を切り替えます。PHP 7 系から 8 系への更新では、廃止された関数や型の扱いの変更で**修正が必要な箇所が出るのがふつう**です。当社が Docker で環境を組む場合は、本番向けの設定ファイルを最初から含めた構成に作り直します。あわせて、CMS とプラグインの更新、不要プラグインの削除、ライブラリの入れ替え、自作部分の点検と修正を行います。 ### 段階4. 継続——監視と定期的な再診断 更新が終わったあとも、サポート期限は次々にやってきます。当社の情報漏洩未然検知サービス「[Previento](https://technosphere.co.jp/previento)（プレビエント）」で Web サーバーのログを24時間監視し、SQLインジェクションなどの攻撃の試行と成功の兆候、Webシェルの設置、設定ファイルの探索を検知します。あわせて、PHP とライブラリのサポート期限を一覧で管理し、期限の前に再診断と更新を提案します。 ** 正直にお伝えしておきたいこと どの対策を組み合わせても、攻撃をゼロにはできません。当社が約束できるのは、**既知の手口で簡単に入られる状態をなくすこと**と、**すり抜けた攻撃に早く気づける状態にすること**の2つです。また、古い PHP の更新はサイトの作りによって修正量が大きく変わるため、段階1の診断結果を見てから作業量と期間をお見積りします。 ## よくある質問（FAQ） Q. PHPのバージョンが古いと、なぜ危険なのですか？ A. サポートが終了したPHPには、新しく見つかった脆弱性の修正が提供されません。脆弱性の情報は公開されるため、攻撃側は手口を知っているのに、守る側だけが直せない状態になります。PHP 7.4・8.0・8.1はすでにサポート終了、8.2も2026年12月31日で終了するため、8.3以降への更新が必要です。 Q. 診断の際にWebサイトを止める必要はありますか？ A. いいえ。当社の診断はPHPの設定値・ライブラリやプラグインのバージョン・公開領域のファイルを読み取るだけで、設定の変更や攻撃を模した大量アクセスは行いません。サイトを停止せず、通常の業務時間内に実施できます。WordPressや他社が制作したサイトも対象です。 Q. PHPを更新するとサイトが動かなくなりませんか？ A. PHP 7系から8系への更新では、廃止された関数や型の扱いの変更により、修正が必要な箇所が出ることがあります。当社は本番と同じ構成の検証環境で先に更新し、エラーの洗い出しと修正、動作確認を済ませてから本番を切り替えます。更新が終わるまでの間は、アクセス制限などの暫定策で攻撃面を減らします。 ## まとめ PHP製Webサイトの穴は、PHP本体・CMSとライブラリ・自作部分の実装・設定と置き忘れの4か所にできます。当社が自社の検証環境を棚卸ししたところ、複数の環境がサポート終了の PHP で動き、設定は開発向けの既定値のまま、公開領域には置き忘れのファイルが残っていました。見つけたものは、公開範囲の制限から順に是正を進めています。**きちんと作られたサイトでも、放置すれば穴は自然に増えます**。 必要な対策は、棚卸し・更新・設定の強化・実装の点検・監視の5つです。最初の一歩は、どこで何が動いているかを知ることから始まります。更新には検証と修正の手間がかかりますが、公開中かつサポート終了という状態を放置するより、ずっと小さいコストです。 当社では、読み取りだけの診断から、暫定策、更新と設定強化、Previento による継続監視までを一連の作業として受け付けています。「自社サイトの PHP が何系か分からない」「制作会社と連絡が取れなくなった」という段階のご相談も歓迎です。