如何保护移动应用程序的 API REST？（如果嗅探请求给了你“钥匙”）

Question

这可能是一个新手问题，但我会尝试创建一个有趣的辩论。

我知道有一些用于 API 基本身份验证、API 密钥、OAuth 2.0 的身份验证方法……所有这些方法都会在请求中添加标头或 formData 参数。

尽管您使用 SSL，但破解移动应用程序“通常很容易”（我现在正在考虑使用 Android：反编译应用程序、更改清单以允许自定义 SSL、再次编译并通过 SSL 代理嗅探所有请求）。

在这些请求中，我发现了很多身份验证密钥，我可以在控制台的其他调用中使用它们，毫无问题地模拟应用程序。

所以，现在我已经在移动应用程序中破解了一些 API，我的问题是：有没有办法保护移动应用程序中的 API？

我想知道一个安全层会限制每个“密钥”的请求数量。

我错了吗 ？我错过了什么吗？这是一个愚蠢的问题吗？

Answer 1

我错了吗 ？这是一个愚蠢的问题吗？

不，你没有错，这根本不是一个愚蠢的问题，因为攻击移动应用程序的 API 服务器确实很容易，而且你会惊讶地发现有多少高级开发人员不知道它是多么容易做到，我注意到，更多的时候则不是，这是由于他们对误解什么VS谁正在访问的API服务器。

之间的区别是什么和谁正在访问的API服务器。

这在我写的这篇文章中有更详细的讨论，我们可以阅读：

向 API 服务器发出请求的内容是什么。它真的是您的移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 之类的工具手动浏览您的 API 服务器？

在谁是移动应用，我们可以验证，授权和以多种方式确定，比如使用OpenID登录连接或流的oauth2的用户。

因此，如果引用的文本不足以阐明您的意思，那么请继续阅读本文的整个部分。

冒充手机APP

在这些请求中，我发现了很多身份验证密钥，我可以在控制台的其他调用中使用它们，毫无问题地模拟应用程序。

如果auth keys你指的是那些通过用户登录提供，用他的用户名和密码，然后他们只是找出谁在请求中。

对于其他密钥，例如api-keys，acess-tokens或用于命名它们的任何其他约定，它们的目的是向 API 服务器提供一种机制，以仅授权来自真正移动应用程序的请求，它们确实试图让 API 服务器识别什么是执行请求，您是否已经发现使用代理很容易提取它们：

尽管您使用 SSL，但破解移动应用程序“通常很容易”（我现在正在考虑使用 Android：反编译应用程序、更改清单以允许自定义 SSL、再次编译并通过 SSL 代理嗅探所有请求）。

因此，归根结底，攻击者所需要的只是使用代理来了解 API 服务器的工作方式，以及模拟 API 调用所需的条件，就好像它是从移动应用程序本身完成的一样。

强化和屏蔽移动应用程序

所以，现在我已经在移动应用程序中破解了一些 API，我的问题是：有没有办法保护移动应用程序中的 API？

您可以使用 Mobile Hardening and Shielding 解决方案，这将尝试阻止移动应用程序在受感染/植根设备、修改/篡改应用程序和/或在运行时使用某些检测框架时工作，但所有这些都具有吸引力- 在移动应用程序中执行所有这些决定的背后，因此可能会被 alreay dito 检测框架操纵或完全绕过，Frida就是一个很好的例子：

将您自己的脚本注入黑盒进程。挂钩任何函数，监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，并立即查看结果。无需编译步骤或程序重新启动。

虽然使用应用内解决方案比不使用任何解决方案更好，但它仍然不是理想的解决方案，因为决定做什么的控制在客户端，而不是在服务器端，因此攻击者可以求助于使用 Frida在运行时内省代码并学习如何模拟移动应用程序。

保护 API 服务器

基本的 API 安全防御

现在你明白之间的区别谁VS什么是访问您的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 - 用户行为分析：

Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全过程。UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测有意义的异常——表明潜在威胁的异常。UBA 不跟踪设备或安全事件，而是跟踪系统的用户。Apache Hadoop 等大数据平台允许它们分析 PB 级数据以检测内部威胁和高级持续威胁，从而增强 UBA 功能。

所有这些解决方案都基于否定识别模型工作，换句话说，他们通过识别什么是坏而不是什么来尽力区分好与坏，因此尽管采用了先进的技术，但它们仍然容易出现误报其中一些使用，如机器学习和人工智能。

因此，您可能会发现自己经常不得不放松阻止对 API 服务器的访问的方式，以免影响好用户。这也意味着该解决方案需要持续监控以验证误报没有阻止您的合法用户，同时他们正确地阻止未经授权的用户。

对于为移动应用程序提供服务的 API，可以通过实施移动应用程序证明解决方案来使用肯定的识别模型，该解决方案在向 API 服务器发出任何请求之前证明您的移动应用程序及其运行的设备的完整性。

一个可能的更好的解决方案

移动应用程序和 API 服务器的当前实现可能如下所示：

这种方法使 API 密钥容易被攻击者通过代理拦截（红线）提取，就像您已经注意到使用代理拦截它们一样。

更好的方法是这样的：

等等，但我在移动应用程序中再也看不到任何 API 密钥了：

我错过了什么吗？

是的，移动应用证明解决方案。

为了处于不需要通过移动应用程序传送任何秘密的位置，那么您需要求助于移动应用程序证明的概念，并且从本文部分我将引用相关部分来解释它的作用：

移动应用程序认证服务的作用是进行身份验证什么是发送请求，因此只响应来自真正的移动应用程序实例来请求，并拒绝未经授权来源的所有其他请求。

为了知道什么是发送请求到API服务器，移动应用程序认证服务，在运行时，将鉴定出具有高可信度，你的移动应用程序存在，没有被篡改/重新包装，是不是在一个根植运行设备，尚未被检测框架（Frida、xPosed、Cydia 等）连接，并且不是中间人攻击 (MitM) 的对象。这是通过在后台运行 SDK 来实现的，该 SDK 将与在云中运行的服务进行通信，以证明其运行的移动应用程序和设备的完整性。

成功证明移动应用程序的完整性后，将发布一个短期存在的JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。在证明失败的情况下，JWT 令牌使用不正确的秘密进行签名。由于移动应用证明服务使用的秘密不被移动应用知道，因此即使应用被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程这就是中间人攻击的目标。

移动应用程序必须在每个 API 请求的标头中发送 JWT 令牌。这允许 API 服务器仅在可以验证 JWT 令牌是否已使用共享密钥签名且未过期时才提供请求。所有其他请求将被拒绝。换句话说有效的JWT令牌告诉API服务器是什么发出请求是上传到谷歌或苹果专卖店的正品移动应用程序，而无效或缺失的JWT令牌意味着什么发出请求没有被授权这样做，因为它可能是机器人、重新打包的应用程序或进行中间人攻击的攻击者。

使用移动应用证明服务的一大好处是其主动和积极的身份验证模型，它不会产生误报，因此不会阻止合法用户，同时阻止坏人。

移动应用认证释放您的移动应用在其代码中嵌入的秘密，而现在它只需要传递到反向代理或后端从移动应用认证服务接收的 JWT 令牌。现在，反向代理或后端可以验证JWT令牌，并在成功验证，他们可以接受具有非常高的信心，他们都源自请求什么，他们预计，移动应用的真正的和真正的实例，用的不是额外的好处公开API 密钥以访问您的 API 服务器或任何第三方服务。

走得更远

如果不向您推荐 OWASP 基金会所做的出色工作，我就无法完成。

对于移动应用程序

OWASP - 移动安全测试指南：

移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。

用于APIS

OWASP API 安全前 10 名

OWASP API 安全项目旨在通过强调不安全 API 中的潜在风险并说明如何减轻这些风险来为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一个前 10 个 API 安全风险文档，以及创建或评估 API 时最佳实践的文档门户。