【要望】ロードバランサー配下での送信元IP取得について

[nglife]

——————————————-
WordPress のバージョン：6.9.7
Welcart のバージョン：2.11.26（→ 2.11.35に上げたのち、2.12.3に上げたい）
PHP のバージョン：8.2
Welcart専用の拡張プラグインとバージョン：-
ご利用の親テーマとバージョン :-
ご利用の子テーマとバージョン :-
利用している決済モジュール：-
症状を確認したブラウザ：-
サーバー【重要】：-
——————————————–

いつもお世話になっております。AWS の ALB 配下（nginx / KUSANAGI）で Welcart を運用しております。2.12.3（2.11.35） のコードを確認したうえでの要望です。

現在、以下の箇所が $_SERVER['REMOTE_ADDR'] を直接参照しています。

– classes/rateLimiter.class.php（会員ログイン試行制限）
– classes/usceshop.class.php の uscescv() / uscesdc()（2.11系 uscesid のIP束縛）
– 各決済クラスの acting_notice_ip_guard() / functions/hoock_func.php の usces_acting_notice_ip_allowed()
– functions/filters.php の wcsite 連携エンドポイントのIP判定

ロードバランサーやリバースプロキシを挟む構成では REMOTE_ADDR がプロキシの内部IPになるため、実際に次の状態になっています。

– 会員ログイン試行制限が機能しない — 全利用者が同一IPとして扱われるため、実質無効か、逆に無関係な利用者を巻き添えでブロックしてしまう。当環境では一度有効化したものの、この理由で無効化せざるを得ませんでした
– uscesid のIP束縛が無効 — 全員が同じIPに見えるため、意図された防御が働いていない
– 決済結果通知のIP許可判定が常に不一致 — コンビニ払い・銀行振込等の入金通知がすべて破棄される

3点目は影響が大きく、たとえば paymentZeus.class.php の acting_notice_ip_guard() は許可IP以外を die( 'error0' ) で終了させます。許可IPはクラス定数 ACTING_NOTICE_IPADDRS のハードコードで拡張用フィルタもないため、サイト側での回避手段がありません。LB配下のサイトが該当決済を有効化すると、入金が反映されないまま滞留することになります。

この種のチェックは 2.11.35 / 2.12.2 以降で順次追加され、2.12.3 でも Telecom Credit のクライアントIPチェック、SBペイメントサービスのオリジンチェック、wcsite 連携エンドポイントの制限が加わりました。セキュリティ強化の方向性には賛同しますが、更新のたびにLB配下での影響範囲が広がっていく状況です。

Webサーバ側で realip 等を設定すれば回避できることは承知の上ですが、私どもの方では諸事情につき（realipの）採用予定はありません。

Welcart 側にて X-Forwarded-For を考慮できる仕組み（信頼プロキシを設定でき、XFFを右から辿って信頼プロキシを除外する方式。WordPress のセキュリティ系プラグインが一般的に採用しています）をご検討いただけないでしょうか。

最小限でも、IP取得を共通関数に集約したうえでフィルタフック（例: usces_filter_remote_addr）を1つ用意していただければ、各サイト側で対応できます。現在は参照箇所がクラスをまたいで分散しているため、サイト側での一括対応ができない点が課題です。

特に会員ログイン試行制限については再有効化を急ぎたいと考えております。

何卒ご検討のほどよろしくお願いいたします。

[efu]

nglife 様

こんにちは。
AWS ALB 配下では、PHP が参照する $_SERVER[‘REMOTE_ADDR’] が、実際のアクセス元ではなくロードバランサーの IP になります。Welcart は IP を用いる判定でこの値を参照しているため、ご指摘の環境では期待通りに動作しません。
信頼プロキシを設定した上で X-Forwarded-For を右側から辿り、信頼プロキシに該当するアドレスを除外して送信元を決定する方式について、方式そのものは妥当なものと考えておりますが、この仕組みを Welcart 本体の設定機能として提供することにつきましては、慎重に判断させていただきたいと思います。
IP 取得処理の共通化とフィルタフックの提供を軸に検討を進めてまいりますが、実装方法および対応時期につきましては、現時点で確定的なことを申し上げられる段階にありません。
方針が固まり次第、改めてお知らせいたします。

[投稿者]

投稿