# 保护自己免受银行卡测试攻击 了解这类欺诈活动及如何保护自己。 银行卡测试是一种欺诈活动，即某些人通过不断尝试来确定盗来的卡是否可用于购物。欺诈者可能通过购买被盗的信用卡信息，然后尝试验证或用这些卡进行购物，以确定哪些卡仍然有效。银行卡测试的其他常用术语有“carding”（信用卡盗刷）、“account testing”（账户测试）、“enumeration”（枚举）以及“card checking”（信用卡查验）。 银行卡测试等欺诈活动是在线商务不可避免的一个部分。但是，银行卡测试会对整个支付生态带来负面影响，因此商家、信用卡组织和 Stripe 都有责任防止这种情况的发生。在 Stripe，我们不断改进我们的欺诈检测和缓解工具和系统，但您也必须对欺诈保持警惕。 ## 银行卡测试是怎样一个过程 测卡分子会通过银行卡设置和支付来确定他们盗来的卡或枚举的信息是否有效。为了快速验证多个卡号，欺诈者会使用脚本一次性测试大量银行卡信息，并收集 3DS 验证或发卡行的响应来验证哪些卡信息有效。识别出有效卡后，他们可以在商家那里购物，或在暗网上转售已确认的卡。 - **银行卡设置** — 这是诈骗者首选的一种方法，因为在持卡设置过程中的银行卡验证和授权信息通常不会显示在持卡人的对账单上。这降低了持卡人发现并举报欺诈活动的可能性。 - **Payments**—银行卡测试人员会进行小额支付，持卡人不太可能注意到这些交易，也不会将其举报为欺诈行为。 ## 银行卡测试后果 银行卡测试有许多负面后果，其中一些会随着银行卡测试的持续而随着时间变得更糟： - **争议** — 很多类型的银行卡测试会涉及到付款，其中一些支付会成功。客户注意到付款成功并将其报告为欺诈，这会导致[早期欺诈预警](https://docs.stripe.com/disputes/measuring.md#early-fraud-warnings)甚至[欺诈性争议](https://docs.stripe.com/disputes.md)，从而浪费您的时间和金钱。 - **更高的拒付率** — 银行卡测试会将大量拒付与您的业务联系起来。高拒付率可能会损害您在发卡行及信用卡组织面前的商誉，从而使您的所有交易看起来都有一定风险。这可能导致合法付款的拒绝率增加，即使在银行卡测试停止后也是如此。 - **额外费用**— 银行卡测试活动可能会产生额外费用，例如自定义定价方案的授权费用以及争议费用。 - **基础设施紧张**— 银行卡测试通常会导致大量网络请求和操作。这种额外的流量可能会使您的基础设施不堪重负，并干扰合法活动。 - **损害生态系统健康** — 银行卡测试会对整个金融系统带来负面影响，因此 Stripe 和我们的金融合作伙伴都希望帮您阻止这种行为。例如，大量导致早期欺诈预警或争议的银行卡测试可能会将您纳入[银行卡监控计划](https://docs.stripe.com/disputes/monitoring-programs.md)。 - **降低业务运营的数据质量** — 来自银行卡测试的收入在您的数据中貌似不错的新客户，因此您很难清楚地看到实际业务增长。 ## 活动卡测试检查表 如果您的集成被测卡分子利用，那么建议您立即采取以下措施： - [识别](https://docs.stripe.com/disputes/prevention/card-testing.md#identify-card-testing) 银行卡测试活动。 - [退还](https://docs.stripe.com/refunds.md)欺诈性付款，以避免争议。 - [使用 Stripe 推荐的集成](https://docs.stripe.com/disputes/prevention/card-testing.md#optimize-integration)或添加[缓解措施](https://docs.stripe.com/disputes/prevention/card-testing.md#control-implementation)来抑制银行卡测试。 - 监测您的集成，确保缓解措施有效。 ## 识别银行卡测试 您可以通过授权失败和付款次数的显著增加来识别大多数银行卡测试活动。大多数攻击在您的 Stripe 管理平台中都能明显看出来。需要注意的常见症状是： - \**失败或被阻止的付款激增。**您可以在[管理平台首页](https://dashboard.stripe.com/dashboard)、[交易](https://dashboard.stripe.com/payments)列表视图中查看趋势，还可以在付款详情页面查看阻止原因。 - **带 402 错误的请求激增**。您可以在[开发人员](https://dashboard.stripe.com/developers)页面查看交易量峰值，在[失败日志](https://dashboard.stripe.com/logs?error_type=card_error)页面检查 402 个故障，或者侦听 webhook 和 API 响应，尤其是有 [generic_decline 结果](https://docs.stripe.com/declines/codes.md)的情况。 - 交易金额低的**可疑付款激增**，通常附有无意义的客户姓名和电子邮件地址。为避免争议，我们建议在这些可疑交易未通过现有防御措施时进行退款。 ## 防止银行卡测试 测卡分子使用多种方法使其欺诈活动难以被阻止。因此，简单的防火墙规则或基于单个启发式方法（如 IP 地址）的过滤器通常不足以阻止银行卡测试。 测卡分子可能使用您的公钥，并用它在您的网站上重试大量付款。对于此类攻击，您有两种主要的缓解策略： - \**使用推荐的 Stripe 集成 — **选择 Stripe 推荐的集成，利用我们已知的有效银行卡测试保护措施。 - \**控制实施 — ** 投资一套控制措施，阻止测卡分子攻击易受攻击的端点。 除了实施缓解策略外，您还要确保密钥安全，并且不要公开发布您的私钥。当您的凭据泄露或被盗时，测卡分子可以使用您的密钥创建付款并设置银行卡。 > 不是开发人员？用插件还是平台？防止和减轻银行卡测试通常涉及到代码级别的更改，因此您需要向编写代码的开发人员或供应商出示该文档，并与他们一起来防止银行卡测试。 ### 使用 Stripe 推荐的集成 如果您使用的是 Stripe 最新的 Payment Element 或 Checkout，我们会有许多自动化和手动控制来减轻银行卡测试，包括速率限制器、AI 模型、验证码触发器、持续审核等。当我们检测到您遭受银行卡测试攻击时，我们会动态选择干预措施来尽可能抑制攻击，同时仍允许合法用户在您的账户上进行交易，并将影响降至最低。您会看到这些付款被标记为 `Blocked by Stripe`。 *然而，Stripe 风控措施的效果取决于您的集成方式以及您向我们发送了哪些风险因素*。我们会使用多种风险因素来区分银行卡测试与合法支付。虽然其中一些风险因素我们会自动计算，但许多因素依赖于您的集成所提供的信息。总的来说，您的集成提供的数据越多，防范银行卡测试的效果就越成功。 我们建议使用 Stripe 的[推荐集成方案](https://docs.stripe.com/payments/online-payments.md#compare-features-and-availability)之一，以利用基于 [CAPTCHA](https://www.hcaptcha.com/) 的自动化保护。现代的 CAPTCHA 解决方案会综合多种风险因素，对高风险行为增加验证难度，同时对服务的合法用户几乎保持无感。如需选择退出我们的 CAPTCHA 集成，请联系 [Stripe 支持团队](https://support.stripe.com/contact/login)。 建议您使用我们推荐的支付集成方案，以便充分利用 Stripe 的银行卡测试防范功能。如果无法使用推荐方案，请尽可能提供更多的数据，或者自行部署风控机制。需要注意的是，虽然银行卡测试防范与 Radar 的欺诈性争议保护是两套独立的机制，但前者同样能从 [Radar 所用的风险因素](https://docs.stripe.com/radar/optimize-risk-factors.md) 中获益。 在您的付款中包含以下信息可能会对 Stripe 的银行卡测试模型的效果产生重大影响。我们推荐的集成使您能够收集这些信息，而直接集成可能需要明确包含这些数据。 - [高级欺诈检测](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection.md) (影响等级最高) - IP 地址 - 客户邮箱 - 客户名称 - 账单地址 ### 控制实施 向目标端点添加限制有助于抑制和防止银行卡测试。实施的限制会使银行卡测试变得不切实际，同时对您的合法流量的影响很小甚至根本没有影响。 测卡分子瞄准的端点通常允许他们执行下列某项操作： - 保存银行卡。 - 进行付款。 根据您的情况和业务需求的不同，向集成中添加的具体安全措施也会有所不同。下面我们介绍几种常见的方法。 ### 实现 CAPTCHA 测卡分子经常使用 CAPTCHAS 可能阻止的自动化脚本。如果您没有使用支持 CAPTCHA 的推荐集成之一，那么这些脚本特别有效。现代 CAPTCHAS 解决方案根据您的需求，提供可见和不可见两种 CAPTCHAS 选项。如果您向集成中添加了 CAPTCHAS，但银行卡测试未停止，则检查以下内容： - 确保验证码对所有启用了银行卡验证请求或 Stripe 的付款请求进行验证。 - 查看 CAPTCHA 文档，确保您已在服务器端实现了该功能。 - 如果您使用的 CAPTCHA 解决方案提供分数，则调整阻止请求成功的阈值。 - 尝试不同的验证码解决方案，例如从不可见验证码切换为可见验证码，或者完全使用不同的验证码解决方案。 ### 限制对您的支付表单的访问 欺诈者越容易访问您的支付表单（例如，使用访客结账），他们就越容易发起银行卡测试攻击。您可以通过要求登录或会话验证来降低银行卡测试者的攻击风险。[防止跨站请求伪造 (CSRF) 攻击的保护措施](https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)对某些类型的银行卡测试也有效，如 CSRF 令牌。 ### 添加速率限制 在某些情况下，您可以通过添加网络速率限制来减少银行卡测试（例如，在网店前端）。调整这些速率限制，以停止您正在经历的特定类型的银行卡测试。例如，如果测卡分子通过将卡绑定到新客户来验证卡，则限制 1 天内单个 IP 地址可以创建的新客户数量就是一种有效的阻止方法。 除了卡组织速率限制之外，您还可以向付款和购物车结账流程添加速率限制，以[检测和防止异常行为](https://docs.stripe.com/disputes/prevention/card-testing.md#prevent-unusual-behavior)，即使在登录或注册后也是如此。 ### 检测和防止异常行为 使用管理平台、[Webhook](https://docs.stripe.com/webhooks.md) 或 [Stripe Sigma 或 Data Pipeline](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) 进行持续监控，以跟踪流量中的异常情况。您可以将卡片测试活动与典型合法流量进行比较，然后构建仅限制或阻止卡片测试活动的筛选器。例如，您可能对系统进行以下更改： - 限制可添加到账户的银行卡数量 - 限制通过单个 IP 地址可创建的客户数量 - 限制可以使用同一产品进行的购买次数 - 限制可创建的同类型客户的数量 - 用某些用户代理或其他参数过滤请求 为此，您可以在 Radar 风控团队版中创建[自定义规则](https://docs.stripe.com/radar/rules/reference.md#velocity-rules)。我们将在下一节讨论。 ### 使用组合缓解措施 结合多种方法减少卡片测试以最大化对欺诈活动的影响，同时不对合法流量产生负面影响可能是有意义的。例如，您可以结合验证码和速率限制，使来自 IP 地址的首次付款尝试无限制成功，但同一 IP 地址在接下来几小时内发出的后续请求需要验证码验证才能成功。 ### 谨慎重试 如果付款出现极端峰值而成功率低，那么过多的重试（催款）可能看起来像银行卡测试。催款和真实银行卡测试攻击可能会对您的业务产生类似的影响，包括发卡行加强风险立场。一定不要在银行卡测试攻击后继续重试在欺诈客户上设置的银行卡，因为这会重复最初的攻击。Stripe 的 [Smart Retries](https://docs.stripe.com/billing/revenue-recovery/smart-retries.md#non-retryable-decline-codes) 已经考虑到了这一点。 ### 根据您的风险偏好定制保护措施 除了实施缓解措施之外，您可能还希望使用 Radar 进一步微调您的保护措施。它带有基于[银行检查](https://docs.stripe.com/radar/rules.md#traditional-bank-checks)的内置规则，例如 *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number) 检查。 如果您了解客户行为，并希望详细自定义支付频率，您可以在 Radar 风控团队版中创建[自定义规则](https://docs.stripe.com/radar/rules/reference.md#velocity-rules)。 您可以在 [Radar 101 指南](https://stripe.com/guides/radar-rules-101#rules-that-help-prevent-card-testing-or-card-cashing)中找到相关示例。 ## See also - [高级欺诈检测](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection.md) - [优化您的 Radar 集成](https://docs.stripe.com/radar/optimize-risk-factors.md) - [保证您的密钥安全](https://docs.stripe.com/keys-best-practices.md) - [Radar 101 指南](https://stripe.com/guides/radar-rules-101)