古いJavaScriptが原因で改ざん広告が表示される サイト脆弱性への対策

古いJavaScriptが原因で改ざん広告が表示される サイト脆弱性への対策

ホームページを運営していると、一番怖いのが「気づかないうちに改ざんされている」という状況です。特に最近多いのが、普通にアクセスしただけなのに怪しい広告が勝手に表示されたり、変なポップアップが出たりするケース。ユーザーからすれば「このサイトは危険かも」と思ってすぐ離脱しますし、Googleのセーフブラウジングに引っかかって警告が出ることもあるので、事業者にとっては信頼の失墜につながります。

実際、サーバー側でWAF（Web Application Firewall）を導入していても、こうした被害を完全には防げないことがあります。WAFは不正アクセスや攻撃パターンをある程度ブロックしてくれる心強い仕組みなんですが、万能ではありません。たとえば古いJavaScriptファイルをそのままテーマやプラグインに残していた場合、そこに脆弱性があれば攻撃者はそこを突いてきます。そして、意外と見落としがちなのが「すでに使っていないけどサーバー内に残っている古いスクリプト」が原因になることなんです。

ある事例では、数年前に導入したスライダー用のJavaScriptをずっと放置していたことが問題でした。そのライブラリ自体に脆弱性があり、最新の攻撃では簡単に改ざんコードを埋め込める状態だった。結果として、正規のページ内に見えない形で広告配信スクリプトを差し込まれ、アクセスしたユーザーにだけ不審なバナーが表示されてしまったんです。サーバーのWAFは新規の不正リクエストには反応しても、既存ファイルが書き換えられる経路までは完全にカバーしきれない場合が多いので、こうしたケースは防ぎきれません。

復旧の流れとしては、まず被害状況の特定が最優先になります。サイトにアクセスして実際に広告が出ているか確認し、ブラウザのデベロッパーツールでソースを調べると、不審な外部ドメインを呼び出しているコードが見つかることがあります。この段階で「どのファイルに仕込まれているのか」「改ざんは1箇所か複数箇所か」を確認していきます。WordPressの場合、テーマのheader.phpやfooter.php、あるいはJavaScriptの外部ファイルに直接仕込まれていることが多い。

次に行うのは不審なコードの除去です。該当するファイルを修正して元の状態に戻すんですが、ここで気をつけなければならないのは「1箇所直したら終わり」と思わないこと。攻撃者がバックドア用のファイルをサーバー内に残していることがあるので、全体をスキャンしてチェックする必要があります。最近ではセキュリティプラグインや専門のマルウェアスキャンツールがあるので、それらを使って不審なコードやファイルを洗い出すのが効果的です。

同時にやるべきなのがサーバーログの確認です。
どの経路から侵入されたのか、どのファイルが書き換えられたのかを追跡して、原因を明らかにしないと再発します。特に古いJavaScriptライブラリやアップデートされていないプラグイン・テーマが原因になることが多いので、そこを最新版に置き換えるか、不要なら削除することが重要です。実際の現場でも「使っていないのにサーバー内に残っていた古いテーマ」や「更新が止まったプラグイン」が原因になるケースはかなり多いです。

復旧作業が終わったら、次は脆弱性対策の強化です。WAFは引き続き有効ですが、それだけでは不十分だと理解しておく必要があります。

具体的には、WordPress本体・テーマ・プラグインを常に最新版に保つこと。さらに古いJSライブラリや外部スクリプトを読み込んでいる場合は、提供元が更新を続けているかどうかを確認して、放置されているものは極力使わないようにする。CDN経由で最新ライブラリを読み込むようにしたり、代替のライブラリに切り替えるのも有効です。

また、ファイルの改ざんを早めに検知できるように仕組みを整えるのも大切です。例えばファイルのハッシュ値を定期的にチェックして差分があれば通知する仕組みや、セキュリティプラグインの改ざん監視機能を活用することで、被害を最小限に抑えられます。被害が長期間放置されると、検索エンジンに危険サイトと判断されてしまい、復旧後も評価が下がってしまうので「早く気づくこと」が大きなポイントです。

さらに一歩進めて考えると、セキュリティ対策というのは「多層防御」が基本です。WAFがあるから安心、セキュリティプラグインを入れたから大丈夫、という単発の考え方ではなく、複数の手段を組み合わせていく。サーバーのアクセス制御やファイルパーミッションの見直し、管理画面のログイン制限や二段階認証の導入、そして日常的なバックアップ。これらを地道にやっておくことで、攻撃されても復旧までのスピードを短縮できます。

実際に被害に遭ったサイトオーナーの中には「WAFを導入していたのになぜ？」という疑問を強く抱く人が多いですが、ここで理解しておきたいのは「WAFはあくまで入り口の攻撃を防ぐもので、内部の古い資産までは守れない」ということです。放置されていた古いJSライブラリや使っていないプラグインは、いわば「裏口が開けっぱなし」になっている状態。玄関に立派な鍵を付けても、裏口が空いていたら意味がないのと同じで、サーバーやCMSを守るなら両方の視点が欠かせません。

「一度被害に遭ったら復旧、その経験を次の対策につなげる」ことです。怪しい広告が出てしまったことでユーザーの信頼を損なったり、検索順位が落ちたりするリスクを考えると、再発を防ぐために予算やリソースを割く価値は十分にあります。セキュリティはコストではなく投資、という意識を持つことが重要です。