这可能是一个新手问题，但我会尝试创造一个有趣的辩论。
我知道API基本身份验证，API密钥，OAuth 2.0有一些身份验证方法...所有这些方法都在请求中添加标头或 formData 参数。
虽然你使用SSL，但破解移动应用程序“通常很容易”（我现在在Android中思考：反编译应用程序，更改清单以允许自定义SSL，再次编译并通过SSL代理嗅探所有请求）。
在这些请求中，我发现了很多身份验证密钥，我可以在控制台的其他调用中使用这些密钥，从而毫无问题地模拟应用程序。
所以，现在我已经在移动应用程序中破解了一些API，我的问题是：有没有办法保护移动应用程序中的API？
我想知道一个证券化层是否会限制每个“密钥”的请求数。
我错了吗？我错过了什么吗？这是一个愚蠢的问题吗？
我错了吗？这是一个愚蠢的问题吗？
不，你没有错，这根本不是一个愚蠢的问题，因为攻击移动应用程序的API服务器确实很容易，你会惊讶地发现有多少高级开发人员不知道它有多容易完成，我注意到，更常见的是，这是由于他们对什么与谁在访问API服务器的误解。
在我写的这篇文章中对此进行了更详细的讨论，我们可以在其中阅读：
向API服务器发出请求是什么。它真的是您的移动应用程序的真实实例，还是一个机器人，一个自动脚本或攻击者使用Postman等工具手动浏览您的API服务器？
谁是移动应用程序的用户，我们可以通过多种方式对其进行身份验证，授权和识别，例如使用OpenID Connect或OAUTH2流。
因此，如果引用的文本不足以澄清您，那么请继续阅读本文的整个部分。
在这些请求中，我发现了很多身份验证密钥，我可以在控制台的其他调用中使用，从而毫无问题地模拟应用程序。
如果你的意思是那些通过用户登录提供的人，他的用户名和密码，那么他们只是识别请求中的人。auth keys
对于其他密钥，如 、或用于命名它们的任何其他约定，它们的目的是向 API 服务器提供一种机制，仅授权来自正版移动应用程序的请求，它们确实试图允许 API 服务器识别正在执行请求的内容，并且您已经发现使用代理提取它们很容易：api-keysaccess-tokens
虽然你使用SSL，但破解移动应用程序“通常很容易”（我现在在Android中思考：反编译应用程序，更改清单以允许自定义SSL，再次编译并通过SSL代理嗅探所有请求）。
因此，在一天结束时，攻击者需要的只是使用代理来了解API服务器的工作原理，以及模拟API调用所需的内容，就好像它是从移动应用程序本身完成的一样。
所以，现在我已经在移动应用程序中破解了一些API，我的问题是：有没有办法保护移动应用程序中的API？
您可以使用移动强化和屏蔽解决方案，这将尝试阻止移动应用程序在受感染/有根设备中工作，修改/篡改的应用程序和/或在运行时使用某些检测框架时，但它们都有在移动应用程序中执行所有决策的缺点，因此可能会被alreay dito检测框架操纵或完全绕过， 一个很好的例子是弗里达：
将您自己的脚本注入黑匣子进程。挂钩任何函数，监视加密API或跟踪私有应用程序代码，无需源代码。编辑，点击保存，并立即查看结果。所有这些都无需编译步骤或程序重新启动。
虽然使用应用内解决方案比不使用任何东西更好，但它仍然不是理想的解决方案，因为决定做什么的控制是在客户端，而不是在服务器端，因此攻击者可以诉诸于使用Frida在运行时内省代码并学习如何模拟移动应用程序。
现在您已经了解了谁与谁在访问您的API服务器之间的区别，并且您知道攻击者可以学习如何模拟您的正版移动应用程序，您可能希望阅读我关于保护API的基本技术的文章：
在本文中，我们将探讨用于保护API的最常见技术，包括使用HTTPS来保护移动应用程序和API之间的通信通道的重要性，如何使用API密钥来识别每个API请求上的移动应用程序，如何将用户代理，验证码和IP地址用于机器人缓解， 最后，用户身份验证对移动安全和 API 安全的重要性。我们将讨论这些技术中的每一种，并讨论它们如何影响业务风险状况，即它们是如何容易解决的。
这只是大多数 API 可能已经采用的非常基本的技术，但它们可以通过一些更高级的技术进行强化。
您可以开始阅读有关移动 API 安全技术的这一系列文章，了解如何使用 API 密钥、HMAC、OAUTH 和证书固定来增强安全性，同时了解如何滥用/击败它们。
之后，根据您的预算和资源，您可以采用一系列不同的方法来保护您的API服务器，我将开始枚举一些最常见的方法和技术。
您可以从reCaptcha V3开始，然后是Web应用程序防火墙（WAF），最后，如果您负担得起，则可以使用用户行为分析（UBA）解决方案。
Google reCAPTCHA V3：
reCAPTCHA是一项免费服务，可保护您的网站免受垃圾邮件和滥用。reCAPTCHA使用先进的风险分析引擎和自适应挑战来防止自动化软件在您的网站上进行滥用活动。它这样做，同时让您的有效用户轻松通过。
...帮助您检测网站上的滥用流量，而不会产生任何用户摩擦。它会根据与网站的互动情况返回分数，并为您提供更大的灵活性来采取适当的操作。
Web 应用程序防火墙（或 WAF）筛选、监视和阻止进出 Web 应用程序的 HTTP 流量。WAF 与常规防火墙的不同之处在于，WAF 能够筛选特定 Web 应用程序的内容，而常规防火墙则充当服务器之间的安全门。通过检查HTTP流量，它可以防止由Web应用程序安全漏洞引起的攻击，例如SQL注入，跨站点脚本（XSS），文件包含和安全配置错误。
Gartner 定义的用户行为分析 （UBA） 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程。UBA 解决方案查看人类行为模式，然后应用算法和统计分析来检测这些模式中有意义的异常，即指示潜在威胁的异常。UBA 不是跟踪设备或安全事件，而是跟踪系统的用户。像Apache Hadoop这样的大数据平台正在增加UBA的功能，允许它们分析PB级的数据来检测内部威胁和高级持续性威胁。
所有这些解决方案都基于负识别模型工作，换句话说，他们尽最大努力通过识别什么是坏的，而不是什么是好的来区分坏的和好的，因此他们很容易出现误报，尽管他们中的一些人使用了先进的技术，如机器学习和人工智能。
因此，您可能会发现自己经常不得不放松阻止对API服务器的访问，以免影响好用户。这也意味着此解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们可以适当地阻止未经授权的用户。
对于为移动应用提供服务的 API，可以通过实现移动应用证明解决方案来使用正标识模型，该解决方案在向 API 服务器发出任何请求之前证明移动应用及其运行的设备的完整性。
移动应用程序和 API 服务器的当前实现可能如下所示：
这种方法使API密钥容易受到攻击者通过代理拦截（红线）提取的原因，就像您已经通过使用代理拦截它们所注意到的那样。
更好的方法是这样的：
等等，但我在移动应用程序中看不到任何 API 密钥：
我错过了什么吗？
是的，移动应用证明解决方案。
要处于不需要随移动应用程序一起提供任何机密的位置，那么您需要诉诸移动应用程序证明概念，在本文部分中，我将引用相关部分来解释它的作用：
移动应用证明服务的作用是对发送请求的内容进行身份验证，从而仅响应来自正版移动应用实例的请求，并拒绝来自未经授权来源的所有其他请求。
为了知道是什么将请求发送到API服务器，移动应用程序证明服务在运行时将高度自信地识别您的移动应用程序存在，未被篡改/重新打包，未在root设备中运行，未被检测框架（Frida，xPosed，Cydia等）挂钩。 并且不是中间人攻击（MitM）的对象。这是通过在后台运行 SDK 来实现的，该 SDK 将与在云中运行的服务进行通信，以证明运行它的移动应用和设备的完整性。
成功证明移动应用完整性后，将颁发一个短生存期的 JWT 令牌，并使用只有云中的 API 服务器和移动应用证明服务知道的机密进行签名。如果证明失败，则使用不正确的机密对 JWT 令牌进行签名。由于移动应用证明服务使用的机密不被移动应用所知，因此即使应用已被篡改、在根设备中运行或通过作为 MitM 攻击目标的连接进行通信，也无法在运行时对其进行反向工程。
移动应用必须在每个 API 请求的标头中发送 JWT 令牌。这允许 API 服务器仅在可以验证 JWT 令牌已使用共享密钥签名且尚未过期时才为请求提供服务。所有其他请求将被拒绝。换句话说，有效的JWT令牌告诉API服务器，发出请求的是上传到Google或Apple商店的真实移动应用程序，而无效或丢失的JWT令牌意味着发出请求的人无权这样做，因为它可能是机器人，重新打包的应用程序或攻击者进行MitM攻击。
使用移动应用证明服务的一大好处是其主动和积极的身份验证模型，该模型不会产生误报，因此不会阻止合法用户，同时阻止坏人。
移动应用证明使你的移动应用在其代码中不再包含嵌入式机密，但现在它只需要将从移动应用证明服务收到的 JWT 令牌传递给反向代理或后端。现在，反向代理或后端可以验证 JWT 令牌，并且在成功验证后，他们可以非常高的可信度接受请求，即它们源自他们所期望的移动应用程序的真实且真实的实例，并具有不公开 API 密钥以访问 API 服务器或任何第三方服务的额外好处。
最后，我不能不向您推荐OWASP基金会所做的出色工作。
移动安全测试指南 （MSTG） 是一本全面的移动应用安全开发、测试和逆向工程手册。
OWASP API 安全项目旨在通过强调不安全 API 中的潜在风险，并说明如何减轻这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一个 Top 10 API 安全风险文档，以及一个文档门户，用于创建或评估 API 时的最佳实践。
