保护API免受滥用(注册和梳理攻击)

Question

我有一个后端(API)和移动应用程序。

移动应用程序用户使用相同的client_id (Oauth2)。

现在我看到许多机器人注册了，增加了信用卡来检查它们(梳理)

我不能节流，限制他们，因为IP总是不同的

你有什么解决办法来阻止它？

如果有一种方法可以唯一地识别每个移动客户端，我可以节流每个请求每秒1次(停止那些自动注册+信用卡添加)。

在过去，欺诈者创建了许多帐户，但也可以使用一个帐户(所以我也可以限制对它的请求)。

解决这个问题的其他办法是什么？

Answer 1

一些建议：

• 重新设计您的OAuth架构。您正在对所有客户端使用相同的client_id，从而有效地启用了对资源的匿名访问。这几乎肯定是错误的。在OAuth中，授权服务器在授权流期间向客户端发出客户端标识符。但是，我不认为这是造成您的问题的原因，因为OAuth不能保护您注册流的入口点。保护这种单一端点的一个典型方法是基于IP的速率限制，但您声称每个注册请求都使用不同的IP，因此这是不可行的。
• 在注册流程中，在可以添加信用卡之前，改进身份验证。这在很大程度上取决于服务的性质(例如，如果需要使用信用卡来验证年龄)，但是一般的想法是增加攻击者创建/丢弃帐户的成本。例如，发送验证邮件会带来较小的时间开销，但丢弃的电子邮件地址很容易创建。在那些SIM卡只能使用身份证，但相对昂贵的国家，向电话号码发送确认短信可能是一种更强的保护。在某种程度上，帐户验证可以外包，例如使用Google登录/使用Apple登录(这将重新引入OAuth!)。如果有人在username+password注册了一个新账户，这可能意味着风险更高。
• 依靠你的平台的能力。由于您正在编写移动应用程序，而不是web应用程序，所以您有一个可以支持您的丰富且相当安全的平台，例如Google API。如果用户的设备没有根植，您可以在应用程序中执行一些速率限制。然而，由于隐私的原因，现代移动OSes避免提供稳定的标识符。您可能可以收集更多的设备信息来创建更准确的风险配置文件，但同样存在隐私/法律/平台方面的影响。
• 外包信用卡处理的更多方面。根据您的上下文，它可能是值得实现应用内支付，而不是通过您的后端处理信用卡信息(也简化了您的遵从性)。虽然这是昂贵的，但有时比你自己对付欺诈要便宜。根据发布应用程序的地点和方式，您可能需要使用Google/Apple支付基础设施。