「セキュリティの問題」警告の消し方｜改ざん特定と再審査
セキュリティの問題が検出された、というメールが届く。あわててサイトを開く。トップも記事ページも、いつも通りに表示される。——それで正常です。改ざんされたコードの多くは、サイトの持ち主のブラウザには出ないように作られています。
だから、最初にやることはサイトを眺めることではありません。Search Console の「セキュリティの問題」レポートで検出内容を控え、攻撃者が狙っている条件のほうを再現して取得し直す。ここが起点です。
Google のヘルプも、こうしたコンテンツを含むサイトについて、サイト所有者は Search Console のセキュリティの問題レポートで違反を確認すべきだとしています。そして対処として挙げているのは3つです。人をだますコンテンツ（欺瞞的コンテンツ）を取り除くこと。第三者から読み込んでいるリソースが欺瞞的でないことを確かめること。そのうえでセキュリティ審査をリクエストすること。
順番が肝心です。削除が先。リクエストは最後です。
レポートで控えるのは3つだけ
画面を開いたら、次の3点をテキストに書き出してください。ここを曖昧にしたまま作業に入ると、あとで「直ったのか」を判定できなくなります。
- 問題の種類。Google のヘルプは、マルウェアと望ましくないソフトウェア、ソーシャル エンジニアリング（フィッシングや詐欺サイト）を、それぞれ別の項目として扱っています。どれに当たるかで、探すコードの見当が変わります。
- 影響を受けたサンプルURL。ここが最大の落とし穴です。サンプルは「見つかった全部」ではなく、あくまで例として示されたものだと考えたほうが安全です。同じ仕組みで他のページも書き換わっている場合があります。
- 検出日。サーバーのファイル更新日時やアクセスログと突き合わせる基準になります。
サンプルURLを1つ直して終わりにすると、審査で戻されることがあります。理由は単純で、直っていないページが残っているからです。
自分のブラウザで再現しないのは、異常ではない
ここが、この問題でいちばん人を混乱させるところです。
改ざんコードは、誰にでも同じものを返すとは限りません。検索結果から来た人にだけ別ページへ飛ばす。特定のブラウザにだけスクリプトを差し込む。管理者としてログインしている間は何も出さない。そういう出し分けをされると、持ち主が普通に見に行っても何も起きません。
Search Console のヘルプは、この再現のためにコマンドラインでの取得例を載せています。Google の検索結果のリンクをたどって、Windows のマシンで www.example.com/page.html を開いた場合を再現する形です。
curl -v --referer "https://www.google.com" \
--user-agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FSL 7.0.7.01001)" \
http://www.example.com/page.html
--referer は「どこから来たか」、--user-agent は「どのブラウザ・OSを名乗るか」を指定するオプションです。ヘルプはこの例に続けて、攻撃者が悪意あるコードを注入している可能性に触れています。つまりこの取得は、隠されている側を引きずり出すための操作です。
実際に1本通してみる
サンプルURLが /blog/2024/03/campaign.html だったとします。同じURLを、条件だけ変えて3回取得し、差分を見ます。
# 1) 素のまま
curl -s https://example.com/blog/2024/03/campaign.html > plain.html
# 2) 検索結果から来た訪問者として
curl -s --referer "https://www.google.com" \
--user-agent "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; FSL 7.0.7.01001)" \
https://example.com/blog/2024/03/campaign.html > fromsearch.html
# 3) 差分を見る
diff plain.html fromsearch.html
差分が空なら、そのページは少なくとも「検索からの流入だけ別扱い」はされていません。次の条件へ移ります。差分が出たら、そこが本体です。多くの場合、末尾に読めない文字列の長いスクリプトが増えていたり、<head> に見覚えのない別ドメインの読み込みが挿さっていたりします。
そして -v（詳細表示）を付けた出力の先頭も見てください。本文が同じでも、ステータスコードが 301 や 302 になって別ドメインへ飛ばされていることがあります。この場合、本文の diff だけを見ていると何も見つかりません。
| 取得の条件 | 何が分かるか | 差分が出たときに疑うところ |
|---|---|---|
素の curl | 誰にでも返る素の状態 | テーマファイルやテンプレートへの直接の書き換え |
リファラを google.com にする | 検索から来た人だけへの出し分け | .htaccess や PHP の先頭に入った振り分け処理 |
| 古い Windows のブラウザを名乗る | 特定環境だけを狙った差し込み | 条件付きで読み込まれる外部スクリプト |
| スマートフォンを名乗る | 携帯だけの転送 | 携帯向けの分岐に仕込まれた転送 |
| ログイン用の情報を付けずに取得 | 管理者に見えない状態 | 管理者判定で隠されている挿入コード |
表は眺めるためのものではないので、1つずつ自分のサンプルURLに当ててください。2つめの「リファラを google.com にする」は、さきほどの fromsearch.html がまさにこれです。3つめは、上の --user-agent をそのまま使えば試せます。4つめだけは値を差し替える必要があります。5つめは、ブラウザではなくコマンドラインで取得している時点で満たしています。
削除から審査リクエストまでの5ステップ
- 記録する。 問題の種類、サンプルURL、検出日を控え、上の方法で取得したHTMLをファイルに保存します。直したあとの比較対象になるので、消さないでください。
- 条件を変えて取得し、差分を出す。 サンプルURLだけでなく、トップページと、同じテンプレートを使っている代表ページも同じ手順で見ます。同じ差分が複数ページに出るなら、共通のテンプレートかサーバー設定に入っていると考えられます。
- 注入箇所を探す。 差分から得た文字列（別ドメイン名やスクリプトの一部）を手がかりに、サーバー上のファイルを検索します。よくある置き場所は、
.htaccess、テーマの共通部品、そして本文データの中です。ファイル一覧を更新日時の新しい順に並べ、検出日前後に変わったものを優先して見るのが早道です。 - 侵入経路をふさぐ。 見つけたコードを消しただけでは、同じ入り口からまた書き換えられることがあります。管理画面と接続用アカウントのパスワードを変える、使っていない拡張機能を削除する、残りを最新版に上げる。ここまでを同じ作業のうちに済ませてください。
- 再取得して、審査をリクエストする。 ステップ2と同じ条件でもう一度取得し、差分が消えたことを確認します。消えていることを確かめてから、セキュリティ審査をリクエストします。
5番の順番を崩さないでください。残ったまま出すと、また同じ画面に戻ってくることになります。
つまずきやすいところ
サンプルURLだけを直す。 これが最も多い形です。示されたURLは例であって全件ではないと考え、同じ経路で書き換わりうる範囲まで確認してください。
外部から読み込んでいるものを見落とす。 自分が書いたコードは全部きれいなのに警告が消えない、という状況はありえます。Google のヘルプは対処として、第三者のリソースが欺瞞的でないことを確かめるよう挙げています。広告の配信タグ、無料の解析用スクリプト、外部から読み込んでいるフォントや部品。自分では書いていないものが、自分のページの一部として動いています。
バックアップに戻して終わりにする。 戻した時点のファイルに、すでに書き換えが入っていることがあります。戻したあとに、必ずステップ2の取得をやり直してください。
HTTPSにすれば消えると考える。 これは別の話です。Google は HTTPS を検索順位の評価に使い始めたと公表していますが、その影響は軽い要素であり、検索のうち1%未満にしか関わらないと説明しています。通信の暗号化は当然やるべきことですが、注入されたコードは暗号化しても注入されたままです。順位の話と警告解除の話を混ぜないでください。
何度も審査をリクエストして様子を見る。 直っていない状態で出し直しても、結果は変わりません。差分が消えたことを自分の手で確認してから出す。それが最短です。
出す前の自己点検
| 確認すること | 判断の基準 |
|---|---|
| レポートの種類とサンプルURLを控えたか | 種類・URL・検出日の3点がテキストに残っている |
| 検索から来た条件で取得し直したか | 素の取得との差分を実際に見た |
| 転送の有無を見たか | ステータスコードが200であることを確認した |
| サンプル以外のページも見たか | トップと代表ページで同じ差分が出ないことを確認した |
| 外部から読み込むものを点検したか | 身に覚えのない外部の読み込みが残っていない |
| 侵入経路をふさいだか | パスワード変更と、拡張機能の削除・更新が済んでいる |
| 修正後に再取得したか | 修正前に保存したHTMLとの差分が消えている |
上から順に埋まってはじめて、審査リクエストを出す準備ができたことになります。1つでも空欄が残るなら、そこを先に閉じてください。
どうしても直せないときは
自分の権限では触れない場所に問題がある、あるいは何度直しても書き換えが戻る。そういう状態はあります。Google のヘルプは、Search Console のユーザーがサイト上で継続する、または修正できないセキュリティ上の問題に直面した場合、Google に知らせることができるとしています。行き詰まったら抱え込まず、その窓口を使ってください。
そのうえで、契約している共用サーバーの管理者や、サイトを作った制作会社にも同時に連絡してください。同じサーバーの別の利用者が原因になっている場合、こちら側のファイルをいくら直しても終わりません。
なお、警告が解除されたあともしばらくは、同じ手順での取得を週に一度ほど続けておくと安心です。差分が出ないことを確認するだけなので、数分で終わります。
このレポートは、サイトの状態をGoogle側から見せてくれる数少ない窓口のひとつです。同じ画面の使い方として、HTTPS関連の警告が出たときの見方や、サーバーエラーが記録されたときの切り分けもあわせて押さえておくと、通知が来たときに慌てずに済みます。
出典