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

Posted 2023-02-23

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

【英文标题】：How to secure an API REST for mobile app? (if sniffing requests gives you the "key")

【发布时间】：2020-06-18 21:57:25

【问题描述】：

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

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

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

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

所以，现在我已经破解了移动应用中的一些 API，我的问题是：有什么方法可以保护移动应用中的 API？

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

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

【参考方案1】：

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

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

what 和 who 访问 API 服务器的区别。

这在我写的this article中有更详细的讨论，我们可以在这里阅读：

what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？

谁是移动应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。

因此，如果引用的文字不足以澄清您，请继续阅读文章的整个部分。

冒充手机APP

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

如果auth keys 是指那些通过用户登录提供的用户名和密码，那么他们只是识别请求中的谁。

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

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

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

强化和屏蔽移动应用程序

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

您可以使用 Mobile Hardening and Shielding 解决方案，该解决方案将尝试阻止移动应用在受感染/root 设备、修改/篡改的应用和/或在运行时使用某些检测框架时运行，但所有这些存在在移动应用程序中执行所有决策的缺点，因此容易被已经使用的 dito 检测框架操纵或完全绕过，Frida 就是一个很好的例子：

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

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

保护 API 服务器

基本的 API 安全防御

现在您已了解 谁 与 什么 访问您的 API 服务器之间的区别，并且您知道攻击者可以学习如何冒充您可能想要的正版移动应用阅读my article 了解保护 API 的基本技术：

在本文中，我们将探讨用于保护 API 的最常用技术，包括使用 HTTPS 保护移动应用程序和 API 之间的通信通道的重要性，如何使用 API 密钥来识别每个应用程序上的移动应用程序API 请求，用户代理、验证码和 IP 地址如何用于 bot 缓解，以及最终用户身份验证对移动安全和 API 安全的重要性。我们将讨论这些技术中的每一个，并讨论它们如何影响业务风险状况，即它们是多么容易绕过。

这只是大多数 API 可能已经采用的非常基本的技术，但可以通过一些更先进的技术来加强它们。

更高级的 API 安全防御

您可以开始阅读Mobile API Security Techniques 上的这一系列文章，了解如何使用 API 密钥、HMAC、OAUTH 和certificate pinning 来增强安全性，同时了解它们如何被滥用/破坏。

之后，根据您的预算和资源，您可以采用一系列不同的方法和技术来保护您的 API 服务器，我将开始列举一些最常用的方法。

您可以从reCaptcha V3 开始，然后是Web Application Firewall(WAF)，最后如果您负担得起User Behavior Analytics(UBA) 解决方案。

谷歌reCAPTCHA V3：

reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。 reCAPTCHA 使用高级风险分析引擎和自适应挑战来防止自动化软件参与您网站上的滥用活动。它在让您的有效用户轻松通过的同时做到这一点。

...帮助您检测网站上的滥用流量，而不会产生任何用户摩擦。它会根据与您的网站的互动返回一个分数，并让您更灵活地采取适当的行动。

WAF - Web Application Firewall:

Web 应用程序防火墙（或 WAF）过滤、监控和阻止进出 Web 应用程序的 HTTP 流量。 WAF 与常规防火墙的区别在于，WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙充当服务器之间的安全门。通过检查 HTTP 流量，它可以防止源自 Web 应用程序安全漏洞的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全错误配置。

UBA - User Behavior Analytics:

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

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

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

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

可能更好的解决方案

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

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

更好的方法是这样的：

等等，但我在移动应用中看不到任何 API 密钥：

我错过了什么吗？

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

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

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

为了了解什么将请求发送到 API 服务器，移动应用证明服务在运行时将高度确定您的移动应用存在，但尚未篡改/重新打包，未在有根设备中运行，尚未被检测框架（Frida、xPosed、Cydia 等）挂钩，并且不是Man in the Middle Attack (MitM) 的对象。这是通过在后台运行 SDK 来实现的，该 SDK 将与在云中运行的服务进行通信，以证明移动应用程序和运行它的设备的完整性。

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

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

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

移动应用证明使您的移动应用不再在其代码中嵌入密钥，而现在它只需要传递到反向代理或后端它从移动应用证明服务接收到的 JWT 令牌。现在反向代理或后端可以验证 JWT 令牌，并且在成功验证后，他们可以非常自信地接受请求，这些请求来自他们所期望的 what，即移动应用程序的真实真实实例，另外还有一个好处是不会公开 API 密钥以访问您的 API 服务器或任何第三方服务。

加倍努力

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

对于移动应用

OWASP - Mobile Security Testing Guide:

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

对于 APIS

OWASP API Security Top 10

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

【讨论】：

这可能是我在这里收到并阅读的最好的答案......非常感谢您的解释，以及对我的问题如此友好。不是每个人都会这样回答......我什至希望删除，但你把我的问题变成了移动应用安全的圣经。再次感谢您！

在答案的中间，我只是在我忘记它之前向上滚动投票！太感谢了。使用 AWS Cognito 或类似的一些服务是一个不错的选择？

AWS Cognito 是用于用户身份验证的，因此它只覆盖了请求中 WHO 的部分，不能对 WHAT 做任何事情正在执行请求。