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