ホームページがいつもどおり表示され、お問い合わせフォームも動いている。そんな状態でも、サイトの裏側では不審なアクセスが発生していることがあります。
攻撃は営業時間に合わせて行われるわけではありません。自動化されたプログラムによる試行は、夜間や休日にも届きます。防御機能の記録を確認して、初めて気づくケースもあります。
そのひとつが「クロスサイトスクリプティング」、略して「XSS」です。
この記事では、XSSがどのような攻撃なのか、WordPressでどこに注意すればよいのか、そして攻撃を検知・ブロックした記録をどう受け止めればよいのかを解説します。
クロスサイトスクリプティング（XSS）とは？
XSSは、Webサイトの表示処理などにある弱点を悪用し、そのページを開いた人のブラウザで、不正なスクリプトを実行させる攻撃です。
スクリプトとは、ブラウザ上で動くプログラムのことです。通常はメニューの開閉や入力チェックなどに使われますが、攻撃者の用意した処理が紛れ込むと、情報の取得や表示内容の書き換えなどに悪用される可能性があります。
ここで重要なのは、不正な処理が動く場所です。
XSSでは、サイトを訪れた一般の利用者だけでなく、管理画面を開いた運営者のブラウザが影響を受ける場合もあります。WordPressのサーバー上で直接プログラムを実行する攻撃とは、仕組みが異なります。
IPAも、検索結果や入力内容の確認画面、コメント表示など、外部から受け取った情報をページに表示する機能で注意が必要としています。
参考：IPA「安全なウェブサイトの作り方 ― クロスサイト・スクリプティング」
XSSが起きる仕組み
例えば、入力された文章をページに表示する機能を考えてみましょう。
本来は、入力内容を文字として安全に表示する必要があります。しかし、その処理に問題があると、攻撃者が仕込んだ内容をブラウザがプログラムとして解釈してしまうことがあります。
基本的な流れは次のとおりです。
- 攻撃者が、入力欄やURLなどに不正な内容を仕込む
- サイトの表示処理に弱点があり、安全に処理されずにページへ反映される
- そのページを開いた利用者のブラウザで、不正な処理が実行される
不審な文字が送られてきただけで、必ずXSSが成立するわけではありません。 入力内容が適切に処理されれば、文字として表示されたり、受け付けずに拒否されたりします。
対策の中心は、外部から受け取った内容を、そのまま実行可能な形で表示しないことです。
XSSでどのような被害が起きる？
影響は、弱点のある場所や、ページを開いた人の権限によって異なります。
| 起こり得る影響 | 内容 |
|---|---|
| 偽の案内や入力欄の表示 | 本物のサイト上に偽の表示を出し、情報を入力させる |
| 情報の取得 | ページ内の情報や、スクリプトからアクセスできる情報を取得する |
| 利用者になりすました操作 | ログイン中の利用者の権限で、操作を行わせる |
| 不審なサイトへの誘導 | 表示やリンクを書き換え、外部サイトへ誘導する |
Cookieなどの保護設定によって、取得できない情報もあります。ただし、Cookieを直接読み取れない場合でも、ログイン中のブラウザを通じて操作される危険は残ります。
管理者が影響を受けると、その権限で可能な操作に悪用されるおそれがあります。一般の閲覧者にだけ関係する問題ではありません。
参考：IPA・XSSで発生し得る脅威、OWASP・XSS対策ガイド
普段どおり表示されていても、気づけないことがある
XSSは、必ずトップページの見た目を大きく変えるものではありません。
特定のURLを開いたときだけ、特定の投稿を表示したときだけ、あるいは管理者が保存された内容を確認したときだけ、問題が表面化する場合があります。
そのため、「ページが崩れていない」「いつもどおり表示される」という確認だけでは、十分とはいえません。
また、自動化された攻撃は、多数のサイトへ機械的に送られることがあります。攻撃らしいアクセスが届いたからといって、そのサイトだけが狙い撃ちされているとは限りません。
サイトの見た目に加えて、更新状況や防御機能の記録を確認する運用が必要です。
知っておきたいXSSの主な種類
XSSの説明では、次の3つの呼び方がよく使われます。
| 種類 | 主な仕組み | 注意する場面の例 |
|---|---|---|
| 反射型XSS | リクエストに含まれる不正な内容が、そのまま応答に反映される | 細工されたURLを開いた際の検索結果やエラー表示 |
| 蓄積型XSS | 保存された不正な内容が、後から表示される | コメント、投稿データ、問い合わせ履歴など |
| DOMベースのXSS | ブラウザ側のJavaScriptが、外部由来の値を危険な方法で画面へ反映する | URLの情報などを使った動的な表示 |
これらは完全に独立した分類ではなく、仕組みが重なる場合があります。
運営者が覚えておきたいのは、送信直後だけでなく、保存した内容を後から表示するときや、ブラウザ側で画面を書き換えるときにも注意が必要という点です。
参考：OWASP・XSSの種類
WordPressでは、どこに注意すればよい？
プラグインやテーマの表示処理
WordPressでは、プラグインやテーマがさまざまな情報を画面に表示します。
フォームの入力内容、検索キーワード、プロフィール、カスタムフィールドなどを扱う処理に弱点があると、XSSにつながる可能性があります。
WordPress本体だけを更新していればよいわけではありません。テーマ、プラグイン、独自に追加した処理も保守の対象です。
管理画面だけに表示する情報
「一般公開していないから安全」とも限りません。
例えば、問い合わせ内容やアクセス記録を管理画面で表示する機能でも、安全な表示処理が必要です。管理者が内容を確認する場面が、攻撃のきっかけになる場合があります。
入力内容を表示する確認画面
フォームの確認画面は、送信前に入力内容を見直すために役立ちます。その一方で、入力内容を再表示する場所でもあるため、適切な処理が必要です。
確認画面があること自体が危険なのではありません。ページ移動型でもポップアップ型でも、入力内容を安全に表示する実装が重要です。
参考：IPA・注意が必要な機能
「XSSをブロックした」という記録は、被害が出たという意味？
防御機能の記録にXSSという言葉があると、不安になるかもしれません。
ただし、「XSSと判定したアクセスをブロックした」という記録と、「XSSが実行されて被害が出た」という事実は別です。
WAFなどの防御機能は、通信の内容が検知ルールに一致すると、攻撃の可能性があるものとして遮断します。正常な入力が誤って判定される場合もあります。
記録だけで、そのサイトに悪用可能なXSSの弱点があると断定することもできません。
| 記録や状態 | 判断するときのポイント |
|---|---|
| XSSとしてブロックされた | 防御機能が、その通信を攻撃の可能性があるものとして扱った |
| 同じような記録が繰り返される | 自動的な試行の可能性を含め、対象URLや発生状況を確認する |
| 記録が見当たらない | 検知対象外の攻撃もあるため、安全の証明にはならない |
| 不審な表示や変更もある | ブロック記録とは別に、実際の影響を調査する |
「ブロックされたから何もしなくてよい」「記録があるから乗っ取られた」と決めつけず、更新状況やサイトの変更履歴とあわせて確認しましょう。
CloudSecure WP Securityによる検知・遮断
CloudSecure WP Securityには、WordPressへの代表的な攻撃を検知するとアクセスを遮断し、履歴を記録する「シンプルWAF」機能があります。
サイトを目で確認していない時間帯でも、機能が有効で正常に動作していれば、処理対象の通信を自動的に検査できます。
こうした仕組みは、夜間や休日も公開し続けるサイトの防御を補助します。
ただし、自動的な検査と、人が記録を確認して対応することは別です。導入した後も、設定が有効か、必要な記録が残っているか、正常な操作に影響していないかを確認する必要があります。
機能の詳細：CloudSecure WP Security公式サイト
WAFは、脆弱性そのものを修正する機能ではない
WAFは、不審な通信を遮断するための補助的な対策です。プラグインやテーマにある表示処理の弱点を、直接修正するものではありません。
また、ブラウザ内だけで処理される情報など、WAFから見えない経路もあります。すべてのXSSをWAFだけで防ぐことはできません。
WAFによる防御と、原因となるプログラムの修正・更新を組み合わせることが基本です。
WordPressで今すぐ確認したいXSS対策
1. 本体・テーマ・プラグインを更新する
管理画面で更新状況を確認し、セキュリティ修正が公開されている場合は、バックアップと必要な動作確認を行って速やかに適用します。
使っていないプラグインやテーマも、依存関係を確認して整理しましょう。修正されない製品を使い続けている場合は、開発元の案内を確認し、代替への切り替えも検討します。
2. 独自の表示処理を確認する
独自テーマやカスタマイズがある場合は、入力された内容をどのように表示しているか、制作・保守担当者に確認してもらいましょう。
WordPressには、表示する場所に応じた処理を行う関数が用意されています。
| 表示する内容 | WordPressで使う代表的な関数 |
|---|---|
| HTML本文中の文字 | esc_html() |
| HTML属性の値 | esc_attr() |
| リンクなどのURL | esc_url() |
| 許可したHTMLを含む内容 | wp_kses()など |
これらは使い分けが必要で、ひとつの関数をすべての場所に使えば安全になるわけではありません。
ブラウザ側のJavaScriptで入力内容を表示する場合も、文字をプログラムとして解釈させない方法を選びます。運営者が自分でコードを書き換えるより、実装を把握している担当者に点検を依頼するのが確実です。
3. WAFを有効にし、正常な操作も確認する
サーバーやセキュリティプラグインのWAF設定を確認します。
有効化後は、記事の保存、画像のアップロード、お問い合わせの送信などをテストしましょう。
正常な操作が遮断された場合は、発生時刻や対象の操作を記録し、検知履歴と照らし合わせます。解決を急いで防御機能全体を無効にするのではなく、原因を確認して必要な範囲だけ調整します。
4. 管理者権限を必要な人に限定する
XSSは、ページを開いた利用者の権限によって影響が変わります。
記事の更新だけを行う担当者に、すべての設定を変更できる管理者権限が必要とは限りません。不要なアカウントや権限を整理しましょう。
強いパスワードや多要素認証も重要ですが、ログイン後のブラウザ内で起きるXSSを、それだけで防げるわけではありません。
5. 検知記録を確認する担当と流れを決める
自動防御を導入しても、誰も記録を確認しなければ、繰り返し発生する問題や誤検知を見逃すことがあります。
次のような項目を、保守担当者と共有しておくと対応しやすくなります。
- いつ発生したか
- どのページや機能が対象になったか
- どのような種類として検知されたか
- 正常な操作への影響があるか
- 不審な表示や変更が同時に起きていないか
記録に含まれる不審なURLや文字列は、確認のためにそのまま開いたり、実行したりせず、調査資料として扱います。
6. 復旧できるバックアップを用意する
バックアップはXSSを防ぐ機能ではありませんが、改ざんなどが起きた場合の復旧に役立ちます。
ファイルとデータベースの両方を保存し、複数世代を保管しましょう。
ただし、脆弱な状態へ戻すだけでは再び攻撃される可能性があります。復旧時は、原因の修正と影響範囲の確認も必要です。
よくある勘違い
| 勘違い | 確認しておきたいこと |
|---|---|
| HTTPSならXSSは起きない | HTTPSは通信を保護しますが、表示処理の弱点は修正しません |
| ログインURLを変えれば防げる | XSSは検索結果や入力内容の表示など、ログイン以外の場所でも起こります |
| コメントを承認制にすれば安全 | 管理画面で確認するときの表示処理にも注意が必要です |
| 入力時にチェックしていれば十分 | 出力する場所に応じた安全な処理も必要です |
| WAFを入れれば更新しなくてよい | 遮断による補助と、脆弱性の修正は別の対策です |
| サイトの見た目が正常なら問題ない | 特定のページや操作だけで影響が出ることがあります |
対策は、ひとつの設定ですべて完了するものではありません。更新、実装、防御、記録の確認を組み合わせて続けることが大切です。
不審な表示や操作が見つかったら
身に覚えのない入力欄が表示される、不審なサイトへ転送される、知らない変更がある場合は、単なるブロック記録とは分けて調査します。
発見日時、ページのURL、画面の状態を記録し、サーバー会社や制作・保守担当者へ連絡してください。
ログなどの記録を保全しながら、必要に応じて該当機能やページへのアクセスを制限します。不審な内容を削除して終わりにせず、原因となった弱点と、利用者への影響を確認する必要があります。
見えない攻撃に備えるために
XSSは、Webサイトの表示処理の弱点を通じて、閲覧者のブラウザに影響を与える攻撃です。普段どおりページが表示されていても、攻撃の試行や問題の存在に気づけないことがあります。
WordPress本体・テーマ・プラグインを更新し、独自の表示処理を点検する。そのうえでWAFによる防御と記録の確認を組み合わせることが、継続的な対策につながります。
WordPress全体の対策については、WordPressのサイバー攻撃対策でも紹介しています。
現在の設定や更新状況に不安がある方は、お問い合わせフォームからご相談ください。