返信先: 不正な会員登録

2024年9月20日 12:25 AM #102542

Alicia

参加者

皆様

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

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

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

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

　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に移行するという仕組みを導入しているところもあるようです。

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

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

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

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