Premmerce Permalink Managerにおける重大なXSS//公開日 2026-05-01//CVE-2024-13362

WP-FIREWALL セキュリティチーム

CVE-2024-13362 Vulnerability

プラグイン名 WooCommerce 用の Premmerce パーマリンクマネージャー
脆弱性の種類 クロスサイトスクリプティング (XSS)
CVE番号 CVE-2024-13362
緊急 低い
CVE公開日 2026-05-01
ソースURL CVE-2024-13362

CVE-2024-13362: WooCommerce 用の Premmerce パーマリンクマネージャーにおける認証されていない反射型 XSS — WordPress サイトオーナーが今すぐ行うべきこと

著者： WP-Firewall セキュリティチーム
日付： 2026-05-01

まとめ

Premmerce パーマリンクマネージャー for WooCommerce (バージョン <= 2.3.11) に影響を与える反射型クロスサイトスクリプティング (XSS) 脆弱性が公開されました (CVE-2024-13362)。認証されていない攻撃者は、エコーされたページレスポンスに JavaScript を注入する URL を作成できます。この脆弱性は反射型 XSS ですが、実際の悪用は通常、特権ユーザー (例えば、ストア管理者) を特別に作成されたリンクをクリックさせたり、悪意のあるページを訪問させたりすることを含みます — この時点で、注入されたスクリプトが管理者のブラウザで実行され、単純なアラートボックスよりもはるかに深刻な影響を及ぼす可能性があります。.

このアドバイザリーでは、技術的詳細、実際の影響シナリオ、サイトが標的にされたかどうかを検出する方法、即時および長期的な緩和策、開発者の修正、そしてベンダーパッチがまだ利用できない場合でも WP-Firewall がどのように保護するかを説明します。.

注記： CVE-2024-13362 はこの問題を指します。脆弱性のクレジットは、それを報告した研究者に帰属します。.

なぜこれが重要なのか (平易な言葉)

反射型 XSS により、攻撃者は作成された URL を訪れる誰のブラウザでも実行されるスクリプトコードを注入できます。もし被害者があなたの WooCommerce サイトの管理者であれば、そのコードは管理者が認証されている間に攻撃者の代理で管理操作を実行できます：

  • 認証クッキーやセッショントークンを盗む
  • ユーザーアカウントを作成または昇格させる
  • メールや支払い設定を変更する
  • バックドアや悪意のあるプラグインをインストールする
  • 商品ページやチェックアウトフローを変更して支払いを傍受する

この特定の脆弱性は WooCommerce ストアで使用されるパーマリンクマネージャープラグインにあるため、損害の可能性にはサイトの妥協と直接的な電子商取引詐欺が含まれます。脆弱なプラグインが低特権であっても、攻撃者はフィッシングやソーシャルエンジニアリングを通じて管理者ユーザーをターゲットにして、完全なサイトの妥協を達成できます。.

技術的要約

  • 製品： WooCommerce 用の Premmerce パーマリンクマネージャー
  • 影響を受けるバージョン: <= 2.3.11
  • 脆弱性の種類: 反射型クロスサイトスクリプティング（XSS）
  • 脆弱性: CVE-2024-13362
  • トリガーするために必要な特権： 悪用を作成するために必要な特権はなし (認証されていない)、しかし悪用には通常、特権ユーザーが悪意のあるリンクと対話することが必要です (ユーザーの対話)。.
  • インパクト： 被害者のブラウザでの任意の JavaScript の実行; 管理者アカウントの妥協が可能。.
  • パッチステータス: 公開時点で、公式のベンダーパッチは利用できませんでした。 (プラグインの著者から新しいリリースがあれば、すぐに適用してください。)

メカニズム (高レベル)： プラグインによってレンダリングされたエンドポイントまたはページは、ユーザーが制御するデータをサニタイズせずにレスポンスに反映します (例えば、ページの一部を構築するために使用されるエコーされたクエリパラメータ)。そのデータに HTML/JS (例: スクリプトタグやイベント属性) が含まれており、アプリケーションがその出力を適切にエスケープまたはサニタイズしない場合、ユーザーが作成された URL を訪れるとブラウザはそれを実行します。.

実際の悪用シナリオ

  1. 管理者をフィッシングする
    • 攻撃者はペイロードを含むURLを作成し、それをメールまたはチャットでストア管理者に送信します。.
    • 管理者（サイトにログイン中）がリンクをクリックします。.
    • 注入されたスクリプトは管理者のコンテキストで実行され、管理者専用のアクション（例：新しい管理者ユーザーの作成、設定の変更、プラグインのインストール）を実行できます。.
  2. 悪意のあるランディングページ + 外部リソース
    • 攻撃者は作成したURLを公共のフォーラムに投稿するか、広告に埋め込みます。.
    • クリックした任意の管理者は脆弱なサイトに到達し、ペイロードを実行します。.
  3. 一般訪問者に対するドライブバイ攻撃
    • 脆弱性がフロントフェイシングページに入力を反映する場合、攻撃者はマーケティングメールや共有リンクにペイロードを埋め込むことで顧客をターゲットにし、クッキーの盗難やターゲットリダイレクト（詐欺/SEOポイズニング）を引き起こすことができます。.

妥協の指標（IoCs）と探すべきもの

あなたのサイトが標的にされたり、侵害された疑いがある場合は、以下を確認してください：

  • 予期しない管理者ユーザーや変更されたユーザーロール。.
  • PHPコードを含むwp-content/plugins、wp-content/themes、またはuploadsの下にある新しいまたは変更されたファイル。.
  • WordPress内の予期しないスケジュールされたタスク（cronジョブ）（wp_optionsの‘cron’を確認するか、WP Controlを使用）。.
  • あなたの知らないところでインストールされた新しいプラグインや変更された設定（ストアのメール、支払いフック）。.
  • 疑わしいクエリ文字列やペイロードのようなパターンを含むGET/POSTリクエストを示すサーバーログ（アクセスログ）。
    • script>
  1. 証拠を隔離し、保存する
    • フルバックアップ（ファイル + データベース）を取り、サーバーログを保存します。これにより、調査と回復が可能になります。.
  2. 露出を減らす
    • 可能であれば、脆弱なプラグイン（WooCommerce用のPremmerceパーマリンクマネージャー）を一時的に無効にします。無効化により、脆弱なコードパスの実行が防止されます。.
    • 無効化が混乱を引き起こし、プラグインをアクティブに保つ必要がある場合は、管理者アクセスを制限します（以下の手順を参照）。.
  3. 管理者アクセスを制限する
    • すべての管理アカウントのパスワードをリセットするよう強制します。.
    • すべての管理者に対して、二要素認証（2FA）を直ちに有効にしてください。.
    • 可能な場合は、IPによって/wp-adminおよび/wp-login.phpへのアクセスを制限してください（例：サーバーファイアウォールまたはWP-Firewallを介して）。.
  4. Webアプリケーションファイアウォール（WAF）ルールと仮想パッチを適用してください。
    • 反射型XSSで使用される一般的なパターンをブロックするWAFルールを展開してください：クエリ文字列またはPOSTデータ内に「<script」、「onerror=」、「onload=」、「javascript:」および類似の疑わしい部分文字列を含むリクエスト。.
    • WP-Firewallの顧客は、反射型XSSパターンを検出してブロックし、公式のプラグインパッチがリリースされるまで脆弱性を仮想パッチする管理ルールを有効にできます。.
  5. ログを監視します。
    • 繰り返しの試行を監視し、サーバーまたはWAFレベルで違反しているIPをブロックしてください。.
  6. 利害関係者への通知
    • インシデントについてホスティングプロバイダーおよび関連する内部チームに通知し、監視と封じ込めを支援できるようにしてください。.

短期的な緩和策（24–72時間）

  • 公式のパッチが利用可能になるまでプラグインを無効のままにしてください。.
  • プラグインがビジネス上の理由でアクティブでなければならない場合：
    • WP-Firewallを使用して、プラグインによって使用される特定のエンドポイントをブロックまたはサニタイズするカスタムルールを作成してください（以下の例のルールを参照）。.
    • 管理アクションを特定のIPまたはVPNアクセスに制限してください。.
    • 厳格なコンテンツセキュリティポリシー（CSP）ヘッダーを強制してください — CSPは入力サニタイズの代替ではありませんが、インラインスクリプトを禁止したり、スクリプトソースを制限することで反射型XSSの影響を軽減できます。.
  • 完全なマルウェアスキャンと整合性チェックを実行してください：
    • 最近変更されたファイルをファイルシステムでスキャンしてください。.
    • コアWordPressファイルを公式のチェックサムと比較してください。.
    • データベース内の注入されたJavaScriptをスキャンしてください（post_content、options、またはwidgets内のスクリプトタグを検索）。.
  • サイトで使用されるAPIキーおよびサービス資格情報（例：決済ゲートウェイ、メールサービス）を予防策としてローテーションしてください。.

長期的な強化（インシデント後および予防）

  • 最小権限の原則:
    • 必要なアカウントにのみ管理者権限を付与してください。.
    • コンテンツエディターと技術管理者のために別々のアカウントを使用してください。.
  • 必須の2FA： すべての特権ユーザーに対して二要素認証を要求します。.
  • プラグインの露出を制限します：
    • 信頼できる著者からのみプラグインをインストールしてください。更新を本番環境に展開する前に確認してください。.
    • 必要なプラグインの数を減らしてください。.
  • ステージングとテスト：
    • 本番環境に展開する前に、ステージング環境でプラグインの更新とセキュリティ修正を検証してください。.
    • カスタムコードをホストしている場合は、CI/CDパイプラインの一部として自動化されたセキュリティテストを使用してください。.
  • すべてを最新の状態に保つ：
    • WordPressのコア、テーマ、プラグインを定期的に更新します。.
    • スタックで使用される重要なコンポーネントのセキュリティ速報を購読してください。.
  • 厳格なCSPヘッダーおよびその他のセキュリティヘッダー（X-Frame-Options、X-Content-Type-Options、Referrer-Policy）を実装してください。.
  • 階層的な防御を使用してください：サーバーファイアウォール、ネットワークレベルのフィルタリング、WAF、およびアプリケーションの強化。.

開発者ガイダンス — 反射型XSSを適切に修正する方法

プラグインまたはカスタムテーマコードを維持している開発者の場合、修正は通常、適切な入力検証と出力エスケープを含みます：

  1. 生のユーザー入力を決してエコーしないでください。
    • HTMLに出力する際は常にデータをエスケープしてください。.
    • HTMLボディテキストの場合：使用する esc_html() または wp_kses() 安全なHTMLの許可リストを使用して。.
    • 属性の場合：使用 esc_attr() または esc_url() （URL用）。.
    • JavaScriptコンテキストの場合：使用する json_encode() そして、JSに安全に出力するために wp_localize_script またはdata-*属性を使用してください。.
  2. 入力を早期にサニタイズします。
    • 使用 テキストフィールドをサニタイズする(), 整数(), absint(), sanitize_key(), 、または他のWordPressサニタイザーを使用して期待されるタイプを強制します。.
    • 受信データが期待される形式（スラグ、整数、メール）に準拠していることを検証してください。.
  3. 状態を変更するアクションにはノンスと能力チェックを使用してください。
    • 常に確認してください 現在のユーザーができる() 管理者のアクションの前に、ノンスを検証します。 wp_verify_nonce().
  4. HTMLレスポンスに信頼できないデータを反映させないでください。
    • ユーザー入力を反映させる必要がある場合（例：検索語）、それをエスケープし、タグとして解釈される可能性のある文字をエンコードすることを検討してください。.
  5. データベースクエリにはプリペアドステートメントを使用してください。
    • ユーザー入力を連結してSQLを構築するのは避けてください — 使用してください。 $wpdb->prepare().
  6. テスト
    • 作成された入力に対して危険な出力が生成されないことを確認するユニットテストと統合テストを追加してください。.
    • 新しいリリースには自動スキャンツールと手動コードレビューを使用してください。.

PHPの安全な出力パターンの例：

<?php

すぐに適用できるWAFルールのサンプル

以下はWAF（mod_security / Nginx / WP-Firewallルールビルダー）で使用できるルールパターンの例です。これらは一般的なパターンです — 正当な入力に対する誤検知を避けるために調整してください。.

注記： 本番環境で有効にする前に、ステージング環境で任意のルールをテストしてください。.

  1. 基本的なスクリプトタグのインジェクションをブロックします（mod_securityのようなルール）
SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS|REQUEST_URI "@rx (<|)\s*script" \n "id:1001001,phase:2,deny,status:403,log,msg:'Reflected XSS - script tag detected',severity:2"
  1. 一般的なインラインイベントハンドラーとjavascript:擬似プロトコルをブロックします。
SecRule ARGS|REQUEST_URI|REQUEST_BODY "@rx (onload|onerror|onmouseover|onclick|javascript:|document\.cookie|window\.location)" \n    "id:1001002,phase:2,deny,status:403,log,msg:'反映されたXSS - インラインイベントまたはJSプロトコル',severity:2"
  1. 管理エリアリクエストに対する高信頼性ルール
    （/wp-adminまたはプラグイン管理エンドポイントへのリクエストのみに適用） 
SecRule REQUEST_URI "@contains /wp-admin" \n "chain,id:1002001,phase:1,deny,log,msg:'Block suspicious admin-area XSS attempts'"
SecRule ARGS|REQUEST_HEADERS|REQUEST_BODY "@rx (<|).*script|onerror|onload|javascript:" \n "t:none"
  1. Nginxの例（サーバーブロックでの基本的なブロック）
if ($arg_custom != "" ) {
  1. WP-Firewall カスタムルール（人間に優しい）
    – 条件：リクエストにクエリパラメータまたは値が正規表現に一致するPOSTフィールドが含まれている
    – 正規表現：(?i)(<\s*script|onerror\s*=|onload\s*=|javascript:)
    – アクション：初回違反者にはブロック、ログ記録、チャレンジ（オプション）；再犯者は自動的にブロック。.

WP-Firewall 管理ルールにはすでに多くのXSSパターンが含まれています — それらを有効にし、ベンダーパッチを待つ間にこのCVEのための仮想パッチを適用します。.

インシデント対応チェックリスト（ステップバイステップ）

  1. ログを保存し、バックアップを取る
  2. 可能であればサイトをメンテナンスモードにしてください。
  3. 脆弱なプラグインを無効化する（またはオフラインにする）
  4. 管理者のパスワードリセットを強制し、2FAを有効にする
  5. 脆弱性パターンを直ちにブロックするWAFルールを適用する
  6. 妨害の兆候（悪意のあるファイル、新しい管理者ユーザー）をサイトでスキャンする
  7. 無許可のユーザーとファイルを削除する
  8. ウェブサイトと関連サービスで使用されるすべての資格情報とAPIキーをローテーションする
  9. 必要に応じて、クリーンなソースから侵害されたファイルを再構築する
  10. 管理者アクセスを強化する（IP制限、2FA、ログイン試行の制限）
  11. 少なくとも30日間、疑わしいフォローアップ活動のためにログを監視する
  12. プラグイン作者から公式パッチが利用可能になったら、ステージングでテストし、本番環境に適用する
  13. 事後分析を行い、得られた教訓に基づいてインシデント対応プレイブックを更新する

完全な侵害がどのように見えるか（なぜXSSを真剣に扱うべきか）

管理者セッションに対する成功した反射型XSSは、局所的な「スクリプトアラート」の迷惑ではありません。管理者のブラウザを通じて、攻撃者は：

  • 更新を通じて持続するバックドアプラグインをインストールする。.
  • 悪意のあるPHPコードを注入するためにテーマやプラグインファイルを修正します。.
  • 顧客のメールを含むデータベースやユーザーリストをエクスポートします。.
  • 支払い設定を変更して支払いを siphon します。.
  • 新しい管理者ユーザーを作成し、データベースに隠します。.
  • マイナーをインストールしたり、SEO/広告詐欺のためにトラフィックをリダイレクトします。.

攻撃は正当な管理者の権限を利用するため、隠密で危険です。修復には通常、コードのクリーンアップとシークレットのローテーションが含まれ、eコマースサイトにとっては高額で混乱を招くものです。.

WP-FirewallがあなたのWordPressサイトを保護する方法（私たちの違い）

WP-Firewallのチームとして、私たちのアプローチはCVE-2024-13362のような問題に対する層状の予防と迅速な緩和に焦点を当てています。

  • 管理されたWAFルール： 反射型XSSや管理者ターゲティングベクターを含むWordPressプラグインパターンに調整されたXSSおよびインジェクションルールを提供し、維持します。.
  • 仮想パッチ: 脆弱性が公開され、公式のパッチがまだ利用できない場合、影響を受けたエンドポイントの攻撃試行をブロックする仮想パッチ（WAFルール）を展開します。これにより、ベンダーの更新を待っている間の露出のウィンドウが閉じられます。.
  • マルウェアスキャンと修復： 自動スキャンは、バックドアやウェブシェルのように見える新しいまたは修正されたファイルを見つけて削除します（有料プランで利用可能）。.
  • 管理エリアの保護： レート制限、IPホワイトリスト、および疑わしい管理リクエストのためのチャレンジページは、成功する管理者指向の攻撃の確率を下げます。.
  • リアルタイムのログ記録とアラート： ブロックされた攻撃試行、疑わしいトラフィックの急増、および繰り返しのプローブ活動に対して即座にアラートを受け取ります。.
  • セキュリティコンサルティングと構成： サイト固有のルールを設定するのを手伝います — 例えば、複数のストアをホストしている場合やCDNを使用している場合、最小限の偽陽性で保護を受けられるようにルールを適応させます。.
  • 透明な脅威インテリジェンス： 私たちのチームはWordPressエコシステムに影響を与える開示（CVE）を監視し、迅速にファイアウォールルールセットにターゲット保護を追加します。.

自動保護（管理ルール）とカスタムルールを作成する能力を組み合わせることで、WP-Firewallはベンダーパッチが保留中であっても脆弱性に対する迅速で低リスクの緩和を可能にします。.

例：反射型XSSのためのWP-Firewall仮想パッチの適用

（概念的なワークフロー — WP-Firewallコンソールはガイド付きインターフェースを提供します。）

  1. 脆弱なエンドポイントを特定します（例：プラグイン管理ページまたは公開URL）。.
  2. 新しいルールを作成します：
    • スコープ：REQUEST_URIに含まれるリクエスト /wp-content/plugins/premmerce-permalink-manager または特定の管理パスへのリクエスト。.
    • 条件：任意のARGSまたはARGS_NAMESが正規表現に一致 (?i)(<\s*script|onerror\s*=|javascript:|document\.cookie|window\.location).
    • アクション：ブロックしてログを記録します。オプションで、403を返し、管理者に通知します。.
  3. テスト：「モニター」モードでルールを有効にして24時間の誤検知を検証し、その後「ブロック」モードを有効にします。.
  4. ログを監視します：高ボリュームの場合、レート制限を適用するか、IP範囲をブロックするか、フロントフェイシングフォームにCAPTCHAを実装します。.
  5. ベンダーパッチが適用され、テストされた後に仮想パッチを削除します。.

このアプローチは、プラグインコードを変更したり、機能を壊したりすることなく迅速な保護を提供します。.

修復後の回復と次のステップ

  • クリーンアップとパッチ適用後、信頼できるソースから変更されたコアまたはテーマファイルを復元します。.
  • 公式リポジトリからプラグインを再インストールし、ベンダーの更新を適用します。.
  • マルウェアスキャンと整合性チェックを再実行して、何も残っていないことを確認します。.
  • 監査ログを確認して、露出のウィンドウ中に不正なアクションが行われていないことを確認します。.
  • 資格情報を再発行し、ユーザーデータが露出した可能性がある場合は顧客に通知します。.
  • プラグインのソーシングポリシーを見直してください — プラグインにセキュリティの不備がある場合は、代替ソリューションやカスタム開発を検討してください。.

実用的な例：XSS攻撃をブロックするための安全な正規表現

これらのパターンを使用して、可能性のあるXSSペイロードを検出します。覚えておいてください：正規表現は誤検知を生む可能性があります — まずはモニターモードでテストしてください。.

  • スクリプトタグを検出します：
    • (?i)<\s*スクリプト\b
  • javascript: 擬似プロトコルを検出します：
    • (?i)javascript\s*:
  • 2. 一般的なイベントハンドラを検出します：
    • (?i)on(?:load|error|mouseover|click|submit)\s*=
  • 疑わしいエンコードされたベクターを検出します：
    • (?i)\s*script|svgonload

これらのチェックをARGS、REQUEST_URI、COOKIE、およびREQUEST_BODYフィールドに適用します。.

ホストと代理店への注意

複数のWooCommerceストアを管理している場合は、デプロイメントパイプラインでこれらの保護を自動化してください。仮想パッチルールは、サイト全体に中央集権的に適用され、露出ウィンドウを即座に閉じることができます。攻撃パターンを監視し、クライアントと調整してプラグインの更新とメンテナンスウィンドウをスケジュールしてください。.

ベンダーパッチが遅れるときにプロアクティブなWAF保護が重要な理由

ベンダーパッチは決定的な修正ですが、必ずしも迅速に到着するわけではありません — そして脆弱性が公開されると、攻撃者はすぐに大規模な悪用を試みます。仮想パッチ機能を持つ管理されたWAFは、その重要なウィンドウの間にリスクを軽減します：

  • WordPressに到達する前に、エッジでの悪用試行をブロックします。.
  • インシデント対応とパッチスケジュールが整うまで、チームが業務を続けられるようにします。.
  • eコマースサイトの顧客の露出と財務リスクを軽減します。.

WP-Firewallの管理されたルール更新と仮想パッチメカニズムは、これらのシナリオに迅速かつ安全に対処するために特別に設計されています。.

今すぐサイトを保護してください：WP-Firewall Basicは、脆弱性を迅速にブロックするのに役立ちます。

タイトル： なぜWP-Firewall Basicが新たなプラグイン脆弱性に対する最初の防御線なのか

WooCommerceストア（または任意のWordPressベースのサイト）を運営している場合、ゼロデイの悪用プローブよりも迅速に反応する保護が必要です。WP-FirewallのBasic（無料）プランは、最も一般的で危険なウェブアプリケーションの脅威をカバーする基本的な管理された保護を提供します：

  • WordPress 用に調整された WAF ルールを持つ管理されたファイアウォール
  • 無制限の帯域幅とリアルタイムブロック
  • 疑わしいファイルや注入されたコードを検出するためのマルウェアスキャン
  • OWASPトップ10攻撃カテゴリ（XSS、SQLi、CSRFを含む）への緩和
  • 必要に応じてカスタム保護を追加できるシンプルなルール管理

今日、無料の基本プランにサインアップして、他の修復手順を適用している間に即座に防御層を追加してください： https://my.wp-firewall.com/buy/wp-firewall-free-plan/

（自動マルウェア除去、IPのブラックリスト/ホワイトリスト、または管理された更新による仮想パッチが必要な場合は、手動の負担を減らし、回復を迅速化するために、スタンダードまたはプロプランを検討してください。）

最終チェックリスト — 今すぐ取るべき迅速なアクション

  • アクティブな場合は、パッチがまだ利用できない場合、WooCommerce用のPremmerceパーマリンクマネージャーを無効にしてください（<= 2.3.11）。.
  • WP-Firewallの保護（管理されたルール）を有効にし、XSSペイロードパターンをブロックするためのターゲットルールを追加してください。.
  • すべての管理者に対してパスワードのリセットを強制し、2FAを有効にしてください。.
  • バックアップを取り、調査のためにログを保存してください。.
  • サイトをスキャンしてクリーンアップし、資格情報を回転させ、フォローアップ活動を監視してください。.
  • プラグインベンダーがパッチをリリースしたら、ステージング環境で適用し、その後本番環境で適用してください。.

最後に

パーマリンク処理と相互作用するプラグインにおける反射型XSSは、小さなコーディングの見落としが攻撃者に限られた脆弱性を完全なサイトの侵害にエスカレートさせる方法の古典的な例です。最も効果的な対応は、即時の封じ込め（プラグインの無効化、WAFルール）、迅速な緩和（仮想パッチ）、および徹底的なクリーンアップ（スキャン、資格情報の回転）を組み合わせることです。.

仮想パッチの適用、管理者専用の保護の設定、またはクリーンアップと強化プロセスの実行に関して支援が必要な場合は、WP-Firewallチームがサポートします。私たちの管理コンソールとルールライブラリは、このような開示ウィンドウ中にWordPressストアを迅速かつ安全に保護するように設計されています。.

安全を保ち、WordPressを最小限に保ち、適切にメンテナンスしてください — 動く部品が少ないほど、攻撃面が小さくなります。.

wordpress security update banner

WP Security Weeklyを無料で受け取る 👋
今すぐ登録!!

毎週、WordPress セキュリティ アップデートをメールで受け取るには、サインアップしてください。

スパムメールは送りません！ プライバシーポリシー 詳細については。

無料のWordPressセキュリティコンサルテーションをご予約いただくには、お問い合わせください。

お問い合わせ

WPファイアウォール
香港、九龍、観塘、洪徳路71号、ザ・レイズ6階

特徴 価格 ブログ ログイン
プライバシーポリシー 利用規約 ドキュメント アフィリエイト

© 2026 WP-Firewall™