カードテスティングの被害を防ぐ

カードテスティングは不正使用行為のひとつで、盗まれたカード情報が有効で購入に使用できるかどうかを他者が確認しようとする行為です。不正使用者は、盗まれたクレジットカード情報を購入して、それらのカードで検証や購入を試み、まだ有効であるカードを特定することがあります。カードテスティングは、「カーディング」、「アカウントテスト」、「エニュメレーション」、「カードチェック」とも呼ばれます。

カードテスティングのような不正使用行為は、オンラインコマースでは避けられないことです。しかしながら、カードテスティングは決済エコシステム全体に影響を及ぼすため、加盟店、カードネットワーク、Stripe は共同で責任を負って防止に努めます。Stripe では、不正使用を検出し低減するためにツールやシステムの改善を続けていますが、お客様も不正使用に対して常に警戒しておく必要があります。

カードテスティングの仕組み

カードテスター (不正使用者) は、カード設定と支払いの両方を利用し、盗難または列挙されたカード情報が有効かどうかを判断します。また、複数のカード番号を迅速に検証するため、スクリプトを使用して大量のカード情報を一度にテストし、3DS またはカード発行会社の回答を収集してどのカード情報が有効かを検証します。有効なカードを識別した後、彼らは加盟店でカードを現金化するか、ダークウェブで確認済みのカードとして販売します。

• カード設定: カード設定中は通常、検証とオーソリがカード保有者の明細書に表示されないため、この方法は不正使用者に好まれます。そのため、カード保有者は不正使用行為に気付いて報告する可能性が低くなります。
• 支払い: カードテスターは、カード保有者が不正使用であることに気づいたり報告する可能性の低い少額の支払いを作成します。

カードテスティングの結果

カードテスティングには多くの悪影響があり、その中にはカードテスティングが続くにつれてさらに悪化するものがあります。

• 不審請求の申請: カードテスティングの類型の多くが支払いに関連するもので、その一部は成功してしまいます。支払いが成功すると、顧客はこれに気付き、不正利用として報告します。これにより、不正利用の早期警告や不審請求の申請が発生し、時間と費用を割かざるを得なくなります。
• 高い支払いの拒否率: カードテスティングは、お客様のビジネスに対する支払いの拒否率の悪化にも関連しています。拒否率が高くなると、カード発行会社とカードネットワークでのビジネスの評価が下がり、その結果お客様の取引のすべてが疑わしく見えるようになりかねません。さらに、カードテスティングが行われなくなった後でも、正当な支払いに対して拒否率が高まる可能性があります。
• 追加手数料: カードテスティング行為により、カスタム料金プランのオーソリ手数料や不審請求の申請手数料など、追加手数料が発生することがあります。
• インフラへの負担: カードテスティングにより、一般的に多くのネットワークリクエストや操作が発生します。これにより増大したトラフィックがインフラに負担をかけ、正当なアクティビティーに影響することがあります。
• エコシステムの健全性への影響: カードテスティングは金融システム全体に悪影響を及ぼします。そのため、Stripe と Stripe の金融パートナーはお客様がカードテスティングを防止できるように支援いたします。大量のカードテストによって不正使用の早期警告や不審請求の申請が発生した場合、お客様はカードモニタリングプログラムに登録される可能性があります。
• ビジネス運営に必要なデータの質の低下: カードテスティングからの収益は、データ上では優良な新規顧客によるものと誤認しかねるため、実質的なお客様のビジネスの成長を明確に把握することが難しくなります。

カードテスティングに関する有効なチェックリスト

カードテスターによって組み込みが悪用されている場合には、直ちに以下のアクションをとることをお勧めします。

• カードテスティング行為を識別します。
• 不正な支払いを返金し、不審請求の申請を回避します。
• カードテスティングを抑制するには、Stripe の推奨システムを使用するか、対策を追加します。
• 導入をモニタリングし、対策に効果があることを確認します。

カードテスティングを識別する

ほとんどのカードテスティング行為は、オーソリと支払いの失敗の著しい増加によって判別できます。ほとんどの攻撃は、Stripe ダッシュボードで確認可能です。注意を必要とする一般的な兆候として、以下のようなものがあります。

• 支払いの失敗またはブロックの急増: この傾向はダッシュボードのホームページ、取引のリストビューで確認できます。また、支払いの詳細ページでブロックの理由を調べることも可能です。
• 402 エラーのリクエストの急増: 開発者ページでエラー件数の急増を確認したり、失敗ログページで 402 エラーを調べたり、「generic_decline」の結果で Webhook や API レスポンスをリッスンしたりすることができます。
• 取引額の少ない疑わしい支払いの急増: 多くの場合、不自然な顧客名やメールアドレスが使用されています。不審請求の申請を回避するために、疑わしい取引が既存の対策を通過した場合は返金することをお勧めします。

支払いがカードテスティングの疑いがあるためブロックされた

カードテスティングを防止する

カードテスターは、その不正使用行為が防止されないように広範なテクニックを駆使します。そのため、IP アドレスのような単一のヒューリスティックに基づく単純なファイアウォール規則やフィルタだけではカードテスティングを防止することはできません。

カードテスターは公開可能キーを使用して、お客様のウェブサイトで複数の支払いを再試行することがあります。このような攻撃に対しては、主に 2 つの対策を用意できます。

• Stripe の推奨システムの使用: Stripe が推奨するシステムを選択して、効果実証済みのカードテスティング保護を利用できます。
• 制御の実装: 制御システムを実装することで、カードテスターによる脆弱なエンドポイントへの攻撃を防止できます。

リスク対策を導入するだけでなく、キーを安全に保管し、シークレットキーを公開しないようにする必要があります。認証情報が漏洩または盗まれた場合、カードテスターはシークレットキーを使用して支払いを作成し、カードを設定することができてしまいます。

Stripe の推奨システムを使用する

Stripe の最新の Payment Element または Checkout を使用している場合、レート制限、機械学習モデル、CAPTCHA トリガー、継続的な審査など、カードテスティングを防止するための自動および手動の制御機能を多数ご利用いただけます。お客様がカードテスティング攻撃にさらされていることが検出されると、Stripe は動的に介入策を選択します。これにより、攻撃が可能な限り抑制され、正当なユーザーはそのアカウントでの影響を最小限に抑えながら取引を行うことができます。これらの支払いは、Blocked by Stripe とマークされます。

「しかし、Stripe の制御が成功するかどうかは、お客様の組み込みと Stripe に送信するシグナルによって決まります」Stripe は、多くのシグナルを使用して、カードテスティングと正当な支払いを区別します。このシグナルの一部は自動的に計算されますが、多くは組み込みによって提供される情報に依存します。一般に、組み込みによって提供されるデータが多いほど、カードテスティング防止の成功度が向上します。

自動化された CAPTCHA に基づく保護を活用するには、Stripe のいずれかの推奨システムを使用することをお勧めします。最新の CAPTCHA ソリューションは、複数のシグナルを適用することでリスクの高い行為に対する規制を強化しますが、お客様のサービスを利用する正規ユーザーにはほとんど影響ありません。CAPTCHA の連携を解除する場合は、Stripe サポートまでご連絡ください。

推奨されている支払いシステムのいずれかを使用すると、Stripe のカードテスティング保護を最大限に活用できます。推奨システムを使用できない場合は、可能な限り多くのデータを含めるか、お客様ご自身で制御機能を導入してください。カードテスティング制御は、不正使用に対する不審請求の申請を防止する Radar の保護とは異なるものですが、Radar で使用されるシグナルと同じシグナルを使用することのメリットがあります。

支払いに以下の情報を含めると、Stripe のカードテスティングモデルの性能に大きな影響を与えることができます。Stripe の推奨システムを使用するとこの情報を収集できますが、直接導入する場合はこのデータを明示的に含める必要があります。

• 高度な不正利用検出 最も大きな影響
• IP アドレス
• 顧客のメールアドレス
• 顧客の名前
• 請求先住所

実装を管理する

対象のエンドポイントに制限を追加すると、カードテスティングを抑制および防止できます。追加する制限によって、カードテスティングを非実際的に使用することができますが、正当なトラフィックにはほとんど影響を与えません。

通常、カードテスターは標的とするエンドポイントで以下のいずれかを行います。

• カードを保存すること。
• 支払いを行います。

システムに追加する具体的なセキュリティ対策は、お客様の状況とビジネスニーズによって異なります。一般的な方法を以下でいくつかご説明します。

CAPTCHA を連携する

多くの場合、カードテスターは CAPTCHA をブロックできる自動スクリプトを使用します。このスクリプトは、CAPTCHA をサポートする推奨システムが使用されていないような場合に特に効果的です。最新の CAPTCHA ソリューションは、お客様の要望に合わせて、表示および非表示の CAPTCHA オプションを両方ご利用いただけます。システムに CAPTCHA を追加してもカードテスティングを阻止できなかった場合は、以下を確認してください。

• Stripe でのカード検証や支払いを可能にするすべてのリクエストで、CAPTCHA による検証を求めるようにします。
• CAPTCHA のドキュメントを見直して、CAPTCHA がサーバー側で連携されていることを確認します。
• スコアを提供する CAPTCHA ソリューションを使用している場合は、リクエストが成功しなくなるレベルまでしきい値を調整します。
• 不可視の CAPTCHA から可視の CAPTCHA へ切り替えたり、まったく異なるソリューションを使用するなど、別の CAPTCHA ソリューションを試します。

決済フォームへのアクセスを制限する

(ゲスト決済を利用するなどして) 不正使用者が決済フォームにアクセスしやすくなれば、不正使用者はカードテスティング攻撃を実行しやすくなります。ログインまたはセッションの検証をカードテスターが支払いを行う前に要求することで、カードテスターによる被害は減らせます。クロスサイトリクエストフォージェリ (CSRF) 攻撃への対抗策の中には、CSRF トークンのように、特定のタイプのカードテスティングに対しても効果的なものがあります。

レート制限を追加する

場合によっては、(ウェブショップのフロントエンドなどで) ネットワークのレート制限を追加することで、カードテスティングを抑制することができます。現在被害を受けている特定のタイプのカードテスティングを防止できるレベルにレート制限を調整してください。たとえば、カードテスターが構築済みのシステムを使用し、カードを新しい顧客に結び付けて検証している場合には、1 つの IP アドレスで 1 日に作成できる新規顧客数を制限することが効果的な防止策となり得ます。

ネットワークレート制限に加え、支払いやカート決済フローにレート制限を追加することで、ログイン後や登録後であっても異常な動作を検出・防止することができます。

異常な動作を検出して防止する

ダッシュボード、Webhook、あるいは Stripe Sigma または Data Pipelines の継続的モニタリングを使用して、トラフィックの異常を追跡します。カードテスティングアクティビティーを一般的な正当なトラフィックと比較して、カードテスティングアクティビティーのみを制限または防止するフィルターを構築できます。たとえば、システムを以下のように変更できます。

• アカウントに追加できるカード数を制限する
• 1 つの IP アドレスで作成できる顧客数を制限する
• 同一商品の購入回数を制限する
• 作成できる同じタイプの顧客数を制限する
• 特定のユーザーエージェントやその他のパラメーターでリクエストをフィルタリングして除外する

この際、Radar for Teams でカスタムルールを活用できます。次のセクションで説明します。

複数の対策を使用する

正当なトラフィックに悪影響を与えずに不正使用行為を最大限抑制するには、複数のアプローチを組み合わせて使用すると効果的な場合があります。たとえば、CAPTCHA とレート制限を組み合わせて、ある IP アドレスからの初回の支払いを制限なく成功させ、その後数時間、同じ IP アドレスからのリクエストに CAPTCHA 検証を要求することができます。

慎重に再試行する

支払いの成功率の低さが相まって件数が増加し、支払いの過度な再試行 (「督促」) が起こっている場合、カードテスティングとみなすことができます。そのため、過度な再試行は、実際のカードテスティング攻撃と同様の影響をビジネスに与える可能性があります (カード発行会社がリスク対応を強化するなど)。カードテスティング攻撃を受けた後に、不正な顧客に対してカード設定を再試行し続けないようご注意ください。Stripe の Smart Retries は、すでにこの点を考慮しています。

リスク選好に基づいて保護機能をカスタマイズする

対策を追加するだけでなく、Radarを使用して保護機能をさらに細かく調整できます。Rader には、セキュリティコードチェックなどの銀行の認証に基づいてブロックする構築済みのルールが組み込まれています。

顧客の行動を把握しており、それを基に支払いの利用頻度の詳細をカスタマイズする場合、Radar for Teams でカスタムルールを構築できます。

Radar の基本ガイドで例を確認できます。