カードテスティングの被害を防ぐ
カードテスティングは不正使用行為のひとつで、盗まれたカード情報が有効で購入に使用できるかどうか何者かが確認しようとする行為です。不正使用者は、盗まれたクレジットカード情報を購入して、それらのカードで検証や購入を試み、まだ有効であるカードを特定することがあります。カードテスティングは、「カーディング」、「アカウントテスト」、「カードチェック」とも呼ばれます。
カードテスティングのような不正使用行為は、オンラインコマースでは避けられないことです。しかしながら、カードテスティングは決済エコシステム全体に影響を及ぼすため、加盟店、カードネットワーク、Stripe は共同で責任を負って防止に努めます。Stripe では、不正使用を検出し低減するためにツールやシステムの改善を続けていますが、お客様も不正使用に対して常に警戒しておく必要があります。
カードテスティングの仕組み
カードテスターは、認証と支払いの両方を使用して、盗んだ、または生成したカード情報が有効かどうかを特定します。
- 認証: 認証は通常カード保有者の明細書に記載されないため、カードテスティングによく使用されます。このため、カード保有者が不正使用行為に気付いたり、報告したりする可能性も低くなります。
- 支払い: カードテスターは、カード保有者が気付いたり不正使用として報告する可能性が低い、少額の支払いをよく使用します。このため、寄付のページや少額の購入が行われるビジネスがカードテスターの理想的なターゲットとなります。
影響
カードテスティングには多くの悪影響があり、その中にはカードテスティングが続くにつれてさらに悪化するものがあります。
- 不審請求の申請: 多くのタイプのカードテスティングには支払いが含まれ、その一部は成功します。支払いが成功すると、顧客がこれに気付き、不正使用として報告します。その結果、お客様にとって時間と費用がかかる不審請求の申請が発生します。
- 高い支払いの拒否率: カードテスティングにより、多くの場合、お客様のビジネスに関連する支払いの拒否率が高くなります。拒否率が高いと、カード発行会社とカードネットワークでのビジネスの評価が下がり、その結果お客様の取引のすべてが疑わしく見えるようになります。このため、カードテスティングが行われなくなった後でも、正当な支払いの拒否率が上がることがあります。
- 追加手数料: カードテスティング行為により、カスタム料金プランのオーソリ手数料や不審請求の申請手数料など、追加手数料が発生することがあります。
- インフラへの負担: カードテスティングにより、一般的に多くのネットワークリクエストや操作が発生します。これにより増大したトラフィックがインフラに負担をかけ、正当なアクティビティーに影響することがあります。
- エコシステム健全性へのダメージ: カードテスティングは金融システム全体に悪影響を及ぼします。そのため、Stripe と Stripe の金融パートナーはお客様がカードテスティングを防止できるように支援いたします。
カードテスティングに関する有効なチェックリスト
カードテスターによって組み込みが悪用されている場合には、直ちに以下のアクションをとることをお勧めします。
- カードテスティング行為を識別します。
- 不正な支払いを返金し、不審請求の申請を回避します。
- カードテスティングを防止するための 1 つまたは複数の対策 を組み込みに追加します。
- 組み込みを監視し、対策に効果があることを確認します。
カードテスティングを識別する
ほとんどのカードテスティング行為は、支払い拒否の著しい増加によって判別することができます。カードテスティングを調査する際には、ダッシュボード内の 3 カ所で支払い拒否を確認できます。ダッシュボードのこれらのセクションは、カードテスティング行為の概要ビューと詳細ビューを提供します。
- カードテスティングが原因でブロックされた支払いは、ブロックされた取引の支払いの詳細を表示すると、その旨が示されます。
- ダッシュボードの開発者セクションにあるグラフは、Stripe アカウントの最近のアクティビティーを表示します。カードテスティングによる支払い拒否率の上昇は、通常これらのグラフに示されます。
- 特定のカードテスティングの支払い拒否は、402 エラーとして失敗したリクエストのログに記録されます。
支払いがカードテスティングの疑いがあるためブロックされた
カードテスティングを防止する
カードテスターは、その不正使用行為が防止されないように広範なテクニックを駆使します。よって多くの場合、ユーザーエージェント文字列などに基づくシンプルなファイアウォール規則やフィルターだけではカードテスティングを防止することはできません。
最も一般的な攻撃方法として、カードテスターは、Stripe シークレットキーを使用して支払いと検証を作成します。必ず、キーの安全性を維持して、シークレットキーを一般に公開しないでください。
注意
開発者以外のお客様や、プラグインやプラットフォームを使用しているお客様の場合、通常、カードテスティングを防止および低減するにはコードレベルの変更が必要とされるため、コードを作成した開発者やベンダーにこのドキュメントを見せて、協力してカードテスティングを防止する必要があります。
Stripe の組み込みを最適化する
Stripe は、レート制限、警告、機械学習モデル、継続的なレビューなど、カードテスティングを防止するための多くの自動および手動の制御機能を備えています。お客様がカードテスティング攻撃を受けていることを最初に検出した際に、当社はできるだけ多くの制御機能を適用し、攻撃の低減に努めます。
「しかし、Stripe の制御が成功するかどうかは、お客様の組み込みと Stripe に送信するシグナルによって決まります」Stripe は、多くのシグナルを使用して、カードテスティングと正当な支払いを区別します。このシグナルの一部は自動的に計算されますが、多くは組み込みによって提供される情報に依存します。一般に、組み込みによって提供されるデータが多いほど、カードテスティング防止の成功度が向上します。
さらに、Stripe が推奨する組み込みとの連携により、疑わしいカードテスティングの支払いに対して CAPTCHA を自動的に実行できるようになります。CAPTCHA は、不正使用者を阻止する効果的なチャレンジですが、正当なユーザーがサービスを利用する際には十分に負荷の少ないものとなっています。Stripe の CAPTCHA 組み込みが適用されないようにするには、Stripe のサポートまでお問い合わせください。
推奨される支払いの組み込みのいずれかを使用すると、Stripe のカードテスティング防止を最大限に活用できます。推奨される組み込みを使用できない場合は、可能な限り多くのデータを含めるか、ご自身で制御機能を導入してください。
組み込みのタイプ | カードテスティングの組み込みの品質 |
---|---|
Stripe Payment Links 推奨 | |
Stripe Checkout 推奨 | |
顧客シグナルとの Stripe Elements推奨 | |
クライアントシグナルおよび顧客シグナルとの直接的な API 組み込み | |
クライアントシグナルとの直接的な API 組み込み | |
顧客シグナルとの直接的な API 組み込み | |
追加シグナルのない直接的な API 組み込み |
決済に以下の情報を含めると、カードテスティングモデルの性能に大きな影響を与えることができます。Stripe で推奨される組み込みを使用するとこの情報を収集できますが、直接的な組み込みではこのデータを明示的に含める必要があります。
- 高度な不正使用検出 最も大きな影響
- IP アドレス
- 顧客のメールアドレス
- 顧客の名前
- 請求先住所
最後に、API キーを使用することで、Stripe のシステムおよびグローバル金融ネットワークにアクセスできるようになりますが、カードテスターはそのアクセスを悪用しようとしているため、キーの安全性を維持し、キーが提供する機能を保護して、不正使用やその他の悪意のある行為を防止することが重要です。
実装を管理する
通常、カードテスターは標的とするエンドポイントで以下のいずれかを行います。
- 顧客にカードを関連付けます。
- 支払いを行います。
この機能を提供するエンドポイントにセキュリティ対策を追加することにより、カードテスティングを防止または緩和できます。導入する制限は、カードテスティングの実行を困難にするものであると同時に、正当なトラフィックには影響を与えないものにする必要があります。
組み込みに追加する特定のセキュリティ対策は、ビジネスの状況とニーズによって異なります。以下に一般的なアプローチをいくつか記載します。
CAPTCHA を追加する
カードテスターは一般的に自動スクリプトを使用しますが、CAPTCHA を使用してブロックすることができます。多くの場合、Google の reCAPTCHA はカードテスティングをブロックするために有効です。ニーズに基づき、可視と不可視の両方の CAPTCHA を使用できます。CAPTCHA を組み込みに追加してもカードテスティングが続く場合は、以下の点を確認してください。
- Stripe でのカード検証や支払いを可能にするすべてのリクエストで、CAPTCHA による検証を求めるようにします。
- CAPTCHA のドキュメントを見直し、正しく導入されていることを確認します。
- スコアを提供する CAPTCHA を使用している場合には、リクエストが成功しなくなるレベルにしきい値を調整します。
- 不可視の CAPTCHA から可視の CAPTCHA へ切り替えたり、まったく異なるソリューションを使用するなど、別の CAPTCHA ソリューションを試します。
レート制限を追加する
場合によっては、レート制限を追加してカードテスティングを防止することができます。発生している特定の種類のカードテスティングを防止するようにレート制限を調整します。たとえば、カードテスターがお客様の実装を使用して、カードを新しい顧客に結び付けて検証している場合には、1 日に 1 つの IP アドレスで作成できる新規顧客数を制限することで、これを効果的に防止できる可能性があります。
ログインまたはセッション検証を要求する
アカウント作成や支払いなどの特定の操作を行う際に、ログインまたはセッションの検証を要求することで、多くの場合カードテスティングを防止できます。クロスサイトリクエストフォージェリ (CSRF) 攻撃への対抗策の中には、CSRF トークンのように、特定の種類のカードテスティングに対しても効果的なものがあります。
異常な動作を検出して防止する
ダッシュボード、Webhook、あるいは Stripe Sigma または Data Pipelines の継続的モニタリングを使用して、トラフィックの異常を追跡します。カードテスティングアクティビティーを一般的な正当なトラフィックと比較して、カードテスティングアクティビティーのみを制限または防止するフィルターを構築できます。たとえば、システムを以下のように変更できます。
- 1 人の顧客に関連付けられるカード数を制限する
- 1 つの IP アドレスで作成できる顧客数を制限する
- 特定のユーザーエージェントやその他のパラメーターでリクエストをフィルタリングして除外する
この際、Radar for Teams でカスタムルールを活用できます。次のセクションで説明します。
リスク選好度に応じてカスタムルールを構築する
Radar は構築済みのルールを備えており、セキュリティコードチェックなどの銀行の認証に基づいてブロックします。
顧客の行動を把握しており、それを基に支払いの利用頻度の詳細をカスタマイズする場合、Radar for Teams でカスタムルールを構築できます。
Radar の基本ガイドで例を確認できます。
複数の対策を使用する
正当なトラフィックに悪影響を与えずに不正使用行為を最大限防止するには、複数のアプローチを組み合わせて使用すると効果的な場合があります。たとえば、CAPTCHA とレート制限を組み合わせて、ある IP アドレスからの初回の支払いを制限なく成功させ、その後数時間、同じ IP アドレスからのリクエストに CAPTCHA 検証を要求することができます。