概要#

Web検索を利用している際、検索結果に表示されたタイトルやスニペットは正常であるにもかかわらず、リンクをクリックした直後に全く無関係な悪性サイト（スパム、フィッシング、偽の警告画面など）へ転送される現象が確認されている。これは偶発的な不具合ではなく、SEOポイズニングおよび**クローキング（Cloaking）**と呼ばれる攻撃手法によるものである。本稿では、その技術的背景と実装メカニズムを解説する。

1. クローキング（Cloaking）：相手によって顔を変える技術#

クローキングとは、Webサーバーがアクセス元の属性（User-AgentやIPアドレス）を識別し、検索エンジンのクローラー（ロボット）と人間のユーザーに対して、それぞれ異なるコンテンツを出し分ける技術である。

攻撃のロジック#

攻撃者は改ざんしたWebサイト（CMSの脆弱性などを突いて乗っ取ったサイト）に、以下のような分岐処理をバックドアとして仕込む。

サーバーサイドでの処理イメージ（擬似コード）#

// 1. アクセス元がGooglebot（クローラー）の場合
// 注意: 単純な文字列一致は容易に偽装可能である（後述）
if (strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') !== false) {
    // 検索順位を上げるための「健全で有益な記事」を表示する
    // これにより、検索エンジンは「このページは安全だ」と評価する
    echo $safe_content_for_seo; 
    exit;
}

// 2. アクセス元がGoogle検索結果からの人間（ユーザー）の場合
// 注意: Refererはブラウザの設定等により送信されない場合がある
if (strpos($_SERVER['HTTP_REFERER'], 'google') !== false) {
    // リファラ（Referer）を確認し、検索経由の訪問者のみを悪性サイトへ転送する
    header("Location: https://malicious-target-site.com/landing");
    exit;
}

// 3. それ以外（直接アクセスなど）
// 管理者に発覚しないよう、何もせず元のページを表示する
echo $original_page_content;

この手法により、検索エンジンのインデックスには「正常なページ」として登録されつつ、実際の検索ユーザーだけが「悪性サイト」への誘導対象となる。

【技術的注意点：判定ロジックの脆弱性】#

User-Agentの偽装: 上記コードのような単純な文字列マッチングは、攻撃者によって容易に欺かれる。正規のGooglebotを識別するには、IPアドレスに対する**逆引き（Reverse DNS）**を行い、ホスト名が googlebot.com や google.com であることを確認した上で、再度正引き（Forward DNS）を行う検証プロセスが必須である。

Refererの信頼性: HTTP_REFERER ヘッダーは、ユーザーのプライバシー設定やブラウザの Referrer-Policy、セキュリティ拡張機能によって削除・改変されることが多い。リファラのみに依存した判定は不確実であり、ログ分析等の補助的な手段が必要となる。

2. オープンリダイレクトとDOM-based XSSの悪用#

クローキングに加え、信頼性の高いドメイン（大学、政府機関、大企業など）に存在する脆弱性が、この攻撃の「踏み台」として悪用されるケースが多い。

なぜ高信頼ドメインを狙うのか#

検索エンジンは、運用歴が長く被リンク数が多いドメイン（Authorityが高いドメイン）を優遇して上位表示する傾向がある。攻撃者は自前のドメインを育てる代わりに、他者のドメイン上のオープンリダイレクト脆弱性やDOM-based XSSを利用して、検索結果に介入する。

攻撃シナリオ#

脆弱性の特定: 攻撃者は、パラメータ検証が不十分なリダイレクト機能を持つサイトを見つける。

// 脆弱な実装例：検証なしにパラメータ先へ転送する
const target = new URLSearchParams(window.location.search).get("url");
if(target) window.location.replace(target);

汚染URLの生成: 攻撃者は以下のようなURLを生成し、SNSや別の改ざんサイトを通じて拡散・インデックスさせる。

https://trusted-university.ac.jp/redirect?url=https://malicious-site.com

ユーザーの被害: 検索結果には「trusted-university.ac.jp」と表示されるため、ユーザーは警戒せずにクリックする。その直後、上記の脆弱なスクリプトが実行され、悪性サイトへ転送される。

3. SEOポイズニングの全体像#

これらを組み合わせることで、攻撃者は以下のようなサイクルを構築する。

キーワード選定: トレンドワードや検索ボリュームの多い専門用語をターゲットにする。

クローキングの実装: 改ざんしたサイトや、脆弱性のある高信頼ドメインを利用して、検索エンジンには「そのキーワードに関連する有益な情報」を見せる。

トラフィックの誘導: 検索結果をクリックしたユーザーに対し、JavaScriptやHTTPヘッダーを用いて即座にリダイレクトを実行する。

4. 攻撃の成立プロセス：侵入を前提としない脆弱性#

【倫理的・法的注意】#

本セクションに含まれる攻撃手法の解説は、Webシステムの脆弱性の仕組みを理解し、適切なセキュリティ対策および検知ロジックを構築するための教育・研究目的で記述されています。これらの手法を自身の管理下にないシステムに対して実行する行為は、不正アクセス禁止法などの法令に抵触する可能性があります。著者は、本情報の悪用によって生じた損害について一切の責任を負いません。

多くのWebサイト管理者は「攻撃者がリダイレクトを仕掛けるには、管理画面への侵入（ログイン）が必要である」と誤解している。しかし実際には、管理権限を奪取せずとも、既存の機能を「発見」して悪用するケースが多発している。その主要なルートは以下の3つに分類される。

ルート1：既存機能の悪用（Google Hacking）#

攻撃者は、自らスクリプトをアップロードするのではなく、サイト内に元から存在する「検証不十分なリダイレクト機能」を探し出す。

手法: Google検索演算子（Google Dorks）を使用し、リダイレクトパラメータを持つURLを機械的に抽出する。
- 検索例: site:target.com inurl:redirect や inurl:link?target=
メカニズム: 言語切り替え機能や外部リンク用クッションページとして設置された正規のプログラムが、入力値（URL）の検証を行っていない場合、攻撃者はそのパラメータを書き換えるだけでオープンリダイレクト攻撃を成立させる。
特徴: サーバーへの侵入は一切不要であり、Webブラウザのみで攻撃が可能である。

ルート2：サプライチェーン攻撃（プラグイン/テーマの脆弱性）#

WordPress等のCMSを利用している場合、コアシステム自体が堅牢であっても、導入したサードパーティ製プラグインに脆弱性が存在するケースである。

手法: 攻撃者は特定のプラグイン（例：アクセス解析ツールやSEOプラグイン）にリダイレクト処理の不備があることを特定すると、そのプラグインを使用しているサイトを無差別に探索する。
メカニズム: プラグイン内のコード（例: header("Location: " . $_GET['url']);）が脆弱であれば、管理者がその危険性を認知していない状態で、外部からリダイレクト機能を利用されてしまう。
特徴: 管理者が意図して設置していない機能が悪用されるため、発見が遅れる傾向にある。

ルート3：バックドアの設置（要・権限奪取）#

前述の2つとは異なり、実際に管理権限（FTP/SSH/CMSログイン）を奪取した上で、攻撃者自身がリダイレクト用のスクリプトを配置するケースである。

手法: 脆弱なパスワードや既知の脆弱性（CVE）を突いてサーバー内部に侵入し、深層ディレクトリ（例: /images/icons/.config.php）などにバックドアを設置する。
メカニズム: .htaccess やNginx設定ファイルを書き換え、検索エンジンからのアクセス（User-Agent）と一般ユーザーを振り分ける「クローキング」などの高度なロジックを実装する場合に用いられる。

防御の視点#

これらすべてを防ぐためには、単に「不正なファイルのアップロード」を監視するだけでは不十分である。 Webアプリケーションファイアウォール（WAF）によるパラメータ検査や、自サイト内の全URLパラメータに対する動的な脆弱性診断（Fuzzing）を行い、「意図せず開いているドア（オープンリダイレクト）」が存在しないかを定期的に確認する必要がある。