不正な会員登録

フォーラム 使い方全般 不正な会員登録

  • このトピックには14件の返信、4人の参加者があり、最後にAliciaにより2週、 4日前に更新されました。
15件の投稿を表示中 - 1 - 15件目 (全15件中)
  • 投稿者
    投稿
  • #102469
    signifiant
    参加者

    ——————————————-
    WordPress のバージョン:6.6.1
    Welcart のバージョン:2.11.2
    PHP のバージョン:8.3.8
    Welcart専用の拡張プラグインとバージョン:無し
    ご利用の親テーマとバージョン :Simplicity2 child 20161002
    ご利用の子テーマとバージョン :Simplicity2 2.8.7.1
    症状を確認したブラウザ:Chrome
    サーバー【重要】:さくら スタンダード
    ——————————————–

    お世話になっております。
    2年ほど前に、不正な会員登録がたくさんあり、その後Recaptchaやメール認証を行うことによって解決していましたが、昨日からまた不正登録が頻繁に起こるようになりました。
    郵便番号や電話番号など、数字しか入力できない部分にも登録不可能なはずのランダムな英文字が入っており(操作ログからの会員情報画像を添付しました)、Recaptchaやメール認証をどのように避けているのかも全く分かりません。
    見つけるたびに削除しておりますが、10分に1度くらい新規に登録されるため、良い気持ちはしません。
    原因あるいは、回避方法をご存知の方おられないでしょうか。

    Attachments:
    You must be logged in to view attached files.
    #102478
    ikeda
    キーマスター

    signifiant様
    こんにちは。
    まず、Welcartは今のところPHP8.3には対応しておりませんので、
    対応バージョンまでダウングレードしていただけますようお願いいたします。
    システム要件をご確認ください。

    現在も不審な会員登録は続いているでしょうか。

    #102498
    signifiant
    参加者

    お世話になります。
    PHPバージョン最新にしておりましたので、8.1まで下げました。

    不正登録ですが、最後は数分に1度くらいの間隔となり、あまりにひどいのであちこち調べまして、functionに下記を追記したことで、ひとまず防ぐことができたようです。

    function mw_usces_filter_member_check($mes)
    {
    $fax = $_POST[“member”][“fax”];
    // FAX番号に数字以外が含まれている場合
    if( strlen($fax) && !preg_match(“/^[0-9]+$/”, $fax) ) {
    $mes .= “FAX番号は半角数字で入力して下さい。<br />”;
    }
    return $mes;
    }
    add_filter(‘usces_filter_member_check’, ‘mw_usces_filter_member_check’, 10);

    とはいえ、FAXに数字が含まれていないことを利用した単純なフィルターですので、最後は対策のいたちごっごになりそうです。
    もし、他により良い方法などありましたら、ご教示いただければ幸いです。

    また、不正登録自体は4月頃から来ていたようで、その頃から隣同士の会員番号の間隔が100番以上飛んでいたため、おそらく登録だけしてメール認証が通らずに自動で消去されていたのではないかと推測しています。

    取り急ぎのご報告となりますが、よろしくお願いいたします。

    #102501
    Alicia
    参加者

    signifiant 様

    こんにちは。

     勉強になります。usces_filter_member_check をこんな風に使ったことはありませんでした。
    さながら、お手製のハニーポットですね。これで防げているのなら、これで様子見ということなりますでしょうか。

     確かに、電話番号はちゃんと数字のみを入れてきてるようですので、これではそのうち突破されるかもしれませんね。
    私は、今のご時世FAXを非表示にしていますので、そういう場合ならFAXを正規表現で数字以外とはせずに、何か入力されたら、即ボット判定としても良さそうです。
    外国からなら、フリガナに正規表現をつけても、それなりの効果が見込めそうです。
    仕組み自体は、Jquery Validation でも可能ですね。

     あとは、よくあるケースとして
    <input type="hidden" name="〇〇" >
    で、最初から人間には見えない落とし穴を作っておくとかでしょうか。

    ハニーポットは、Welcart 本体でも搭載されると便利かもしれませんね。(このような古い技術では、今となっては、あまり意味がないのかもしれませんが・・・。)

     ただ気になるのが、Google reCAPTCHA v3 がちゃんと仕事をしていないような気がしますので、一度確認された方が良いのではないかと思います。

    Welcart Shop システム設定 > Google reCAPTCHA v3 において

     「Google reCAPTCHA v3 動作中response_OK」

    と表示されていますでしょうか?

     また、スコア(閾値)は、いくつになっていますでしょうか? 
    デフォルトで 0.5 ですが、小さ過ぎるとボットを通過させやすくなります。
    デフォルトより、1.0 に近づけるとより厳しい判定になりますが、厳しすぎると人間も通さなくなります。
    一度、1.0 (人間でも 100% ボット判定される)にして、ご自身でフォームに入力してみて、ちゃんと機能しているかご確認ください。テスト後は、スコアを戻すのをお忘れなく。

     メール認証が突破されてるのも気になります。さっぱり分かりません。なんか悔しいです。これもちゃんと動いてますか?

    不正登録自体は4月頃から来ていたようで、

    この頃に、PHPのバージョンを、8.2以上にしてしまわれたのでしょうか?この頃は、メール認証は機能していて防げていたのに、

    昨日からまた不正登録が頻繁に起こるようになりました。

    ということは、9/6直前に、サーバー環境や新たなプラグインなど何か環境に影響を与える要因があって、ついにメール認証まで突破され、登録を許してしまったという流れでしょうか。

     PHPのバージョンを正されたので、すでにそれだけで reCAPTCHA やメール認証が復活し、解決しているかもしれませんし、そうなれば、FAX の対策も不要かもしれません。また、経過を共有いただけるとありがたいです。

    #102505
    ikeda
    キーマスター

    Alicia 様
    いつもありがとうございます。

    signifiant 様
    PHP ダウングレードの対応ありがとうございます。
    Alicia 様が仰るように、Google reCAPTCHA v3 と 新規登録時のメール認証 の機能が正常に動作しているかをご確認いただけますでしょうか。
    現状ひとまずは止まったということですが、引き続き経過を見ていただけたらと思います。

    #102511
    abisissy
    参加者

    こんにちは、横から失礼します。私共のサイトも同様です。

    4月頃に始まったのも同じで、今現在は1日0~10数件程度あります。
    ごくまれにメール認証を突破してきます(これまでに数件ほど)。
    それ以上の被害はないので様子見でいたのですが…

    電話番号以外はランダムな大小英字(数字がない)で登録してあるので、郵便番号などに何らかのバリデーションを入れればいいのかなと思ってはいたのですが、signifiant様のFAXに入れるアイデアはいいですね。

    これは、Welcart様のほうで実装はされないでしょうか?

    ——————————————-
    WordPress のバージョン:6.6.2
    Welcart のバージョン:2.11.2
    PHP のバージョン:8.0.30
    Welcart専用の拡張プラグインとバージョン:
     WCEX DL Seller 3.5.4
     WCEX Widget Cart 1.2.5
     WCEX Patch for AFC 6.0.3
     WCEX Favorites 1.0.4
    ご利用の親テーマとバージョン :Total 5.19
    ご利用の子テーマとバージョン :上記の子テーマ
     ショップ部分のベースは Welcart Basic 1.8.5
    症状を確認したブラウザ:Chrome
    サーバー【重要】:Xserverビジネス

    Google reCAPTCHA v3動作中response_OK スコア0.6
    ——————————————–

    #102513
    Alicia
    参加者

    abisissy 様

    情報共有ありがとうございます。
    PHP8.0 適正 スコア0.6 ですか。人力でやれそうな頻度でしょうか?
    signifiant 様は、

    不正登録ですが、最後は数分に1度くらいの間隔となり、あまりにひどいのであちこち調べまして

    と仰ってます。
    これらは、本当に不具合なしで reCAPTCHA v3 突破してるんでしょうか。だとすれば、今後被害が増えるかもしれませんね。

    これは、Welcart様のほうで実装はされないでしょうか?

    どうなんでしょうね。判断が分かれるところかも。突破された人が少数ならば、フックで今のところ対応できそうですし。
     そもそもバリデーションで簡易なハニーポット作るよりも、reCAPTCHA v3 の方が格段に精度が高いイメージがあるので、実装したところで・・・というのもあります。不具合が確認されてるわけでもありませんし。
     メール認証含め、まずは突破された方の情報が集まらないと何とも言えないかもです。

    #102514
    signifiant
    参加者

    皆様

    色々とご教示いただき、ありがとうございます。
    迷惑登録も収まっていましたので、PHPを8.1とした後、FAX部分のフックを外しまして様子見をしていますが、
    現在のところ新規の登録は来ていません。引き続き様子を見ます。

    reCAPTCHAですが、PHP 8.3の時にスコアを0.8としたところ、自分のテストでも弾かれたので正常に動いていたのではないかと思うのですが、1度しかテストしなかったため余り自信がありません。
    また、0.8に上げていた時にも迷惑登録は続いていて、これは手に負えないと思った記憶がありますが…これも自信無しです。
    PHP8.1に戻した後数回テストしましたが、スコア1.0で間違いなく弾かれました。

    PHPのバージョンを上げたのがいつなのか、全く覚えていないので、こちら方面での情報をお出し出来なくて申し訳ないです。
    その他思い当たるのが、最近気付いたのですが、Wordfenceが「Unite Gallery Lite」と「YARPP」という2つのプラグインについて致命的という警告を出していたのが、ちょうど9月9日でした。
    Unite Galleryは「削除済みプラグイン」としてプラグインリストから外されており、YARPPの方は「プラグイン脆弱性」で「脆弱性の深刻度: 5.3/10.0 (中)」となっていました。

    Unite Galleryは大したことに使っていないので良いのですが、YARPPは関連商品表示に使っていたため、どうしたものかと、こちらも様子見をしている状態です。

    様子見ばかりとなってしまいましたが、何か進展がありましたらこちらに書かせていただきます。

    #102515
    abisissy
    参加者

    皆様

    こちら、reCAPTCHAのスコアは、signifiant様同様、0.7や0.8に上げてみたこともあったのですが状況は変わらず、関係はわかりませんが同時期にお客様からログインできないという連絡もあったので、現状0.6です。

    人力で対応というか、仮登録はあってもメール認証されなければ、一日ほど経てば自動的に会員リストから削除されるので、それに任せています。
    正式登録されなければ、会員登録メールも来ませんし。

    4~5月頃、ひどいときは数分に一度あったりしましたが、今現在はだいぶ減り、一日0件だったり、10数件だったりです。

    様子見しかできませんね…

    ※PHPのバージョンは、WCEX Favoritesプラグインが8.0までしか対応していないので上げられません。

    #102521
    ikeda
    キーマスター

    皆さま貴重なご意見をいただき誠にありがとうございます。

    abisissy様
    取り急ぎ下記について回答させていただきます。

    ※PHPのバージョンは、WCEX Favoritesプラグインが8.0までしか対応していないので上げられません。

    WCEX Favorites は PHP8.1 に対応しております。
    対応バージョンの更新が遅くなり大変申し訳ありません。

    #102530
    ikeda
    キーマスター

    皆さま
    この度は貴重なご意見をありがとうございました。
    Welcart での対策を前向きに検討したく存じます。
    不審な会員の情報がまだ残っている(会員データを削除していない)方はいらっしゃいますか?
    参考のため不審な会員データをいくつか共有いたたきたく思います。

    #102532
    abisissy
    参加者

    ikeda様
    PHPの対応ありがとうございます。

    会員データ、あります。本日は多めに来ています。
    添付いたします。

    Attachments:
    You must be logged in to view attached files.
    #102535
    ikeda
    キーマスター

    abisissy 様
    スクリーンショットのご提供有難うございます。
    こちらCSVでお送りいただくことは可能でしょうか。
    Welcart Management 会員リスト > 操作フィールド内 > [会員データ出力]
    可能な場合はこちらのフォームからご連絡いただけますと幸いです。
    (フォームからCSVファイルを添付することはできませんので、お手数ですが、弊社から返信いたしましたメールに添付する形でご連絡いただけますと幸いです)

    #102541
    Alicia
    参加者

    ikeda 様

     いつもお世話になっております。
    Welcart での対策をご検討いただけるとのこと、ありがとうございます。

     拡張プラグインについての、下記のご回答につき、他の拡張プラグインについても確認させてください。

    WCEX Favorites は PHP8.1 に対応しております。
    対応バージョンの更新が遅くなり大変申し訳ありません。

     私も、abisissy 様同様、拡張プラグインのPHP8.1対応待ちになっています。
    拡張プラグインの中には、他にも PHP8.0 となったままの表記が複数あるのですが、それらも PHP8.1対応済みとなっていたりするのでしょうか?

     確か、Welcart Shop > ホーム 内の右側にある 「Welcart インフォメーション」において、Ver.2.10 の頃は、「Welcart 本体はPHP8.1に対応していますが、拡張プラグインの中には、まだ対応していないものがある」と表記されていたと記憶しています。Ver.2.11~は、そのような表記はなくなりました。このことを持って、全ての拡張プラグインは、PHP8.1 に対応済みと理解してよいものでしょうか?
    Welcart システム要件については、「PHP 7.4から8.1」と明記されていますので、各拡張プラグインの【対応バージョン 】表記の更新が遅れているだけで、実際は対応済みとなっていますか?

     もし、WCEX Favorites だけ 対応バージョンの更新が遅くなっていたのでしたら申し訳ないことなのですが、Welcart Ver.2.11.3 現在で、 PHP8.1未対応の拡張プラグインがある場合は、まとめてご案内いただけますと幸いです。

    #102542
    Alicia
    参加者

    皆様

    情報提供に感謝いたします。

    どうやら、Google reCAPTCHA v3 もメール認証も不具合があるわけでもないのに突破されてるようですね。

    reCAPTCHA v3 は、その仕組み自体がブラックボックスになっておりますので、どういう方法ですり抜けたのかもわかりません。
    スコア(閾値)も0.5以上ですし、上げすぎるとカゴ落ちリスクが高まるだけに及び腰になるのも無理もありません。

     私も素人ですので間違いがあると思いますが、いくつか気になる点がありまして、可能性として一つの実験的な考察をここに残しておこうと思います。フォーラムご利用の方からのご意見がいただけると嬉しいです。

     reCAPTCHA v3 のGoogle側のスコアの精度について、各サイトで結構バラツキがあるのではないかと思っています。これによって、脆弱なサイトと強固なサイトに分かれているのではないかと怪しんでいます。

     多くのWelcart ユーザーは、お問い合わせフォームとして推奨されている Contact Form 7 をお使いだと思います。そして、Contact Form 7 にも reCAPTCHA v3 が利用できるようになっていて併用されているのではないかと思います。

     reCAPTCHA v3 のバッヂはGoogleに認められている方法で普段非表示にしているのですが、これを表示するように戻して、自分のサイトをチェックすると、ほぼ全てのページでバッヂが表示されます。Contact Form 7 の作者は、このことに関して丁寧に説明されていて、Googleの公式では、出来るだけ多くのページで reCAPTCHA v3 を読み込ませることが精度向上のために望ましい旨述べられていると、記されています。つまりフォームのないページでの訪問者が実際に辿った動線データもボットと人間を区別する重要な要素となりうるということになります。

     一方、試しに Contact Form 7 を無効化してキャッシュをクリアすると、Welcart が reCAPTCHA v3 を読み込ませているページにのみバッヂが表示されるようになるのですが、ログインページやカート遷移中のページなど一部に限定されています。これは、Google が提唱する利用方法ではないのかもしれません。だからと言って、スコアの精度が悪いとは言い切れないのですが、可能性としてはあり得る話ではないかと思っております。

    Contact Form 7 のユーザーでも、お問い合わせフォーム以外のページに読み込ませるとサイトが重くなるので、「plugin load filter」などのプラグインで読み込むのを制限している人もいるようです。

    そこで、ひとつの可能性として、Google reCAPTCHA v3 の運用上の理想の環境作りという視点でできることはないかと、二つ考えました。

     一つは、単純に、Welcart がGoogle reCAPTCHA v3 を読み込ませるページの範囲を拡張すること。
     もう一つは、Contact Form 7 と Welcart で reCAPTCHA v3 を共同利用できないかということです。

     共同利用については既に実行されているケースもあるのではないかと思います。
    私はこれまで、Contact Form 7 と Welcart で別々の reCAPTCHAキーを利用してきました。
    ここ数年、reCAPTCHA v3 の誤判定に悩まされていまして、試行錯誤している最中なのですが、reCAPTCHAキーを一つにまとめてしまえば、サイト全体としてのスコアの精度が上がるのではないかと予想しています。

     スコアの精度が目に見えるわけでもないので立証できないのですが、特に反証がないのであればやってみる価値はあるかもしれません。まとめてしまえば、結果的に、Welcart も訪問者が実際に辿った動線データを全てのページから取得できるようになるのではないかと考えます。(ここは、全くの素人考えなので、自信はありません。)
     そうすることで、執拗に不正にユーザー登録ばかりを繰り返そうとするのを防いでくれるようになるのではないかと期待しています。

     一つにまとめるとデメリットもあります。このデメリットゆえにこれまで別々の reCAPTCHAキー を利用していたのですが、突破されるより全然良いと思いますので、実験結果によっては、今後考えを改める必要が出てくるのかもしれません。

    以下は、Gemini に聞いてみた結果です。

    Google reCAPTCHA v3 において、reCAPTCHA のキーは、プラグイン毎に分ける方が良いのか、共通のreCAPTCHA のキーを使用する方が良いのか、どちらですか?

    回答案を表示

    Google reCAPTCHA v3 のキーについて:プラグイン毎と共通のどちらがよいのか
    Google reCAPTCHA v3 のキーをプラグイン毎に分けるか、共通のキーを使用するかは、サイトの規模、セキュリティ要件、管理のしやすさなど、複数の要素を考慮して決定する必要があります。

    【プラグイン毎にキーを分ける場合のメリット・デメリット】

    メリット:
    セキュリティの強化: 各プラグインのトラフィックを個別に監視できるため、特定のプラグインを狙った攻撃をより早期に検知できます。
    柔軟性: プラグインごとに異なるスコアリングを設定できるため、よりきめ細かい制御が可能になります。
    トラブルシューティングの容易化: 問題が発生した場合、原因を特定しやすいです。

    デメリット:
    管理の煩雑化: 複数のキーを管理する必要があり、手間がかかります。
    パフォーマンスへの影響: キーの数が多くなると、ページの読み込み速度が遅くなる可能性があります。

    【共通のキーを使用する場合のメリット・デメリット】
    メリット:
    管理の簡便さ: 1つのキーで全てのプラグインをカバーできるため、管理が容易です。
    パフォーマンスの向上: キーの数が少ないため、ページの読み込み速度が速くなります。

    デメリット:
    セキュリティリスクの増大: 特定のプラグインが攻撃された場合、他のプラグインにも影響が及ぶ可能性があります。
    柔軟性の低下: 全てのプラグインに同じスコアリングが適用されるため、きめ細かい制御が難しいです。

    【どちらを選ぶべきか】
    一般的に、以下の場合はプラグイン毎にキーを分けることを検討する価値があります。
    サイトの規模が大きく、複数のプラグインを使用している場合
    各プラグインのセキュリティレベルに差がある場合
    高度なセキュリティ対策が必要な場合

    一方、以下の場合は共通のキーを使用することを検討できます。
    サイトの規模が小さく、プラグインの数が少ない場合
    セキュリティよりもパフォーマンスを重視する場合
    管理の負担を軽減したい場合

    【その他の注意点】
    スコアリング: reCAPTCHA v3 は、0から1までの間のスコアを返します。このスコアに基づいて、ボットかどうかを判断します。プラグインごとに最適なスコアリングを設定することで、セキュリティとユーザビリティのバランスを取ることができます。
    エラー処理: reCAPTCHA の設定ミスやネットワークエラーが発生した場合、適切なエラー処理を行う必要があります。
    定期的な見直し: reCAPTCHA の設定は、定期的に見直すことが重要です。Googleは、reCAPTCHAのアルゴリズムを常に改善しているため、古い設定では効果が得られない可能性があります。

    【まとめ】
    reCAPTCHA のキーをプラグイン毎に分けるか、共通のキーを使用するかは、サイトの状況や要件によって最適な選択が異なります。どちらを選ぶにしても、メリットとデメリットをしっかりと理解し、慎重に判断する必要があります。

    より詳しい情報を得るためには、以下の点を考慮して検討することをおすすめします。

    サイトの性質: ウェブサイトの種類、規模、扱うデータの重要度など
    セキュリティ要件: どの程度のセキュリティレベルが必要か
    パフォーマンス: ページの読み込み速度など
    管理のしやすさ: 管理者のスキルや時間など
    もし、より具体的なアドバイスが必要であれば、サイトの状況について詳しく教えてください。

    参考情報:

    reCAPTCHA v3 のサイトキーとシークレットキーの取得方法: https://csgaku.com/blog-tech/recaptchav3/
    ウェブサイト用の reCAPTCHA キーを作成する: https://cloud.google.com/recaptcha-enterprise/docs/create-key-website?hl=ja
    免責事項:

    上記の情報は、一般的な情報であり、個々の状況に合わせた最適なアドバイスではありません。 最終的な判断は、ご自身で行ってください。

     その他としましては、Google reCAPTCHA v2 は、面倒ですが案外有効だったりするかもしれません。
    ネット情報ですが、v3 のスコア(閾値)を若干厳しく設定しておいて、ボット判定されたときは、自動的にv2に移行するという仕組みを導入しているところもあるようです。

    続いて、メール認証についてです。

     ご提供いただきました会員情報画像から、メールアドレスについて任意の10件を調べてみましたら、9件が過去に流出したメールアドレスとして登録されていました。 (参考:https://haveibeenpwned.com/ Have I Been Pwned (HIBP) API: 世界最大規模のデータ漏洩情報データベースの一つです。)

     なので、こちらは、適当な実在しないメールアドレスではなく、実在するメールアドレスかと思われます。
    何かチート的な方法ですり抜けたのかと思っていましたが、自動化した上で正攻法でメール認証を突破したのかと想像します。
     当初は、不正な会員登録をしてきたメールアドレスをブラックリストとして登録できるようにすればいいのかと単純に考えていたのですが、毎回違うメールアドレスですし、そもそも、Welcart では既に登録された会員のメールアドレスは、重複して利用できない仕様となっており、これではブラックリスト化する意味もないことに気づかされました。
     となると、Have I Been Pwned (HIBP) API やDehashed API、CyberChef といった外部APIサービスと連携できるようにしない限り、メール認証は突破され続けるのではないかと思います。これは、メール認証の性質として宿命みたいなものですね。一筋縄ではいかないかもしれません。

    長文大変失礼しました。よろしければ皆様のご意見をお待ちしております。

15件の投稿を表示中 - 1 - 15件目 (全15件中)
  • このトピックに返信するにはログインが必要です。