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

Question

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

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

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

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

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

我想知道一个证券化层将是限制每个“密钥”的请求数量。

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

Answer 1

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

[没有，您没看错，这根本不是一个愚蠢的问题，因为攻击移动应用程序的API服务器确实很容易，而且您会惊讶地知道有多少高级开发人员不知道这有多么容易完成，并且我注意到，通常情况不是这样，这是由于他们对what vs who正在访问API服务器的误解。

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

我写的this article中对此进行了更详细的讨论，我们可以在其中阅读：

what是向API服务器发出请求的东西。它确实是您的移动应用程序的真正实例，还是机器人，自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛？

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

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

模拟移动APP

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

如果用auth keys表示您是通过用户登录名提供用户名和密码的，那么他们只是在请求中标识who。

对于其他键，例如api-keys，acess-tokens或用于命名它们的任何其他约定，它们的目的是向API服务器提供一种仅授权来自真正移动应用程序的请求的机制，实际上，他们确实试图允许API服务器标识what正在执行请求，并且您是否已经发现使用代理轻松提取它们：

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

因此，最终，攻击者需要使用代理来了解API服务器的工作方式，以及模拟API调用（就像从移动应用程序本身进行的操作一样）。

保护API服务器

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

您可以使用移动强化和屏蔽解决方案，该解决方案将尝试阻止移动应用程序在经过修改/篡改的应用程序和/或在运行时使用某些检测框架的情况下，在受感染/已root用户的设备中工作，但是它们都具有在移动应用程序中执行所有决策的缺点，因此容易受到alreay dito工具框架的操纵或完全绕开，这是一个很好的例子，它是Frida：

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

虽然使用应用程序内解决方案比不使用任何东西要好，但它仍然不是理想的解决方案，因为决定做什么的控制权是在客户端，而不是在服务器端。

一种可能更好的解决方案

[移动应用程序和API服务器的当前实现可能看起来像这样：

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

更好的方法是这样的：

“ >>>

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

我想念什么吗？

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

[无需在移动应用程序中附带任何秘密的位置，那么您需要诉诸移动应用程序证明概念，在this article section中，我将引用相关部分来说明其作用：

移动应用程序证明服务的作用是验证发送请求的内容]，因此仅响应来自真正移动应用程序实例的请求，并拒绝来自未授权来源的所有其他请求。

为了知道what将请求发送到API服务器，移动应用程序证明服务将在运行时高度肯定地标识您的移动应用程序存在，未被篡改/重新打包，不在根设备中运行，没有被工具框架（Frida，xPosed，Cydia等）迷住，也不是Man in the Middle Attack (MitM)的对象。这是通过在后台运行SDK来实现的，该SDK将与在云中运行的服务进行通信以证明其运行的移动应用程序和设备的完整性。

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

移动应用必须在每个API请求的标头中发送JWT令牌。这允许API服务器仅在它可以验证JWT令牌已使用共享密钥签名并且尚未过期时才服务请求。所有其他请求将被拒绝。换句话说，有效的JWT令牌会告知API服务器what

发出的请求是上传到Google或Apple商店的真正移动应用程序，而无效或丢失的JWT令牌则表示what正在发出请求该请求无权这样做，因为它可能是机器人，重新打包的应用程序或发起MitM攻击的攻击者。

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

移动应用程序证明使您的移动应用程序免于在其代码中嵌入秘密，而是现在仅需要传递给反向代理或对从移动应用程序证明服务接收到的JWT令牌进行后端处理。现在，反向代理或后端可以验证JWT令牌，并且在成功验证后，他们可以非常有信心地接受请求，这些请求是由他们期望的what

发起的，该请求是移动应用程序的真实实例。不使用[[暴露

API密钥来访问您的API服务器或任何第三方服务的附加好处。超速行驶

[我不建议您完成OWASP-移动安全测试指南中所做的出色工作，因此无法完成：

移动安全测试指南（MSTG）是用于移动应用安全开发，测试和逆向工程的综合手册。