移动后端API密钥的安全性

Question

假设我正在开发一个移动应用程序，该应用程序可以调用API服务器。API服务器由API密钥保护。

我无法在移动应用程序内部对API密钥进行硬编码，因为它可能被盗。

如何保护API密钥？

Answer 1

假设我正在开发一个移动应用程序，该应用程序可以调用API服务器。API服务器由API密钥保护。

首先，让我们清除一下开发人员中关于API的一个非常普遍的误解...

WHO和与您的API服务器进行通讯之间的差异

为了更好地了解WHO和WHAT在访问您的移动应用程序之间的区别，让我们使用以下图片：

预期的通信渠道代表合法用户合法使用您的移动设备，而该用户没有任何恶意意图，使用移动应用程序的未修改版本，并直接与API服务器通信，而不会受到中间人的攻击。

实际渠道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用您的移动应用程序的重新打包版本，黑客使用您的移动应用程序的真实版本，而中间人则在攻击它以了解通信方式为了能够自动针对您的API进行攻击，移动应用程序与API服务器之间的连接已完成。其他许多情况也是可能的，但在此我们将不逐一列举。

我希望到现在为止您可能已经有了线索，为什么WHO和WHAT并不相同，但是如果不是这样，那一会儿就会明白。

该世界卫生组织是移动应用程序，我们可以验证，授权和以多种方式确定，比如使用OpenID登录连接或流的oauth2的用户。

绿洲

通常，OAuth代表资源所有者向客户端提供对服务器资源的“安全委派访问”。它为资源所有者指定了一个在不共享凭据的情况下授权第三方访问其服务器资源的过程。OAuth专为与超文本传输​​协议（HTTP）配合使用而设计，本质上允许访问令牌由授权服务器在资源所有者的批准下发布给第三方客户端。然后，第三方使用访问令牌访问资源服务器托管的受保护资源。

OpenID连接

OpenID Connect 1.0是基于OAuth 2.0协议的简单身份层。它允许客户端基于授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终​​用户的基本配置文件信息。

虽然用户认证可以让你的API服务器知道世卫组织正在使用的API，它不能保证请求源自什么你期待，你的移动应用程序。

现在，我们需要一种方法来确定什么是呼唤你的API服务器，这里的事情变得比大多数开发人员可能会觉得更靠谱。在什么是发出请求到服务器API的东西。它确实是您的移动应用程序的真正实例，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具手动在您的API服务器上戳戳？

令您惊讶的是，您可能最终发现它可能是您的合法用户之一，他们使用重新打包的移动应用程序版本或自动脚本来游戏化并利用您的服务。

好了，要确定WHAT，开发人员通常会使用通常在其移动应用程序代码中进行硬编码的API密钥。一些开发人员付出了更多的努力，并在移动应用程序中在运行时计算了密钥，因此与将静态机密嵌入代码中的前一种方法相反，它成为了运行时机密。

以上文章摘自我写的一篇文章，标题为《为什么您的移动应用程序需要API密钥？，您可以在此处完整阅读，这是有关API密钥的系列文章中的第一篇。

你的问题

因此，无论使用Oauth，OpenID还是任何其他类型的身份验证，都无法通过身份验证/授权服务器解决您的问题，因为如您现在所了解的那样，此服务器将仅识别WHO正在访问您的API服务器，而不是什么是访问它。

明确地说，我并不是说不应该使用这种方法，实际上，使用Oauth2 / OpenID是识别WHO正在访问API服务器的最佳方法。

现在，您可能正在思考如何解决问题：

我无法在移动应用程序内部对API密钥进行硬编码，因为它可能被盗。

好吧，您使自己头疼，没有医生或药物能使它消失。

的确，如果您在移动应用程序中隐藏了任何秘密，则可以对其进行反向工程。在本文中，我介绍了通过使用JNI / NDK在移动应用程序中隐藏API密钥的最有效方法之一，但与此同时，我也介绍了如何对其进行反向工程：

现在是时候寻找一种更高级的技术来隐藏API密钥了，这种方式很难从APK进行反向工程，为此，我们将利用JNI利用本地C ++代码存储API密钥。使用NDK的界面。

在开始回答您的问题之前，我完成了我的下一篇文章的草稿，该草稿是关于如何执行中间人攻击以窃取API密钥的，您将可以阅读以下内容：

尽管我们可以使用高级技术（例如JNI / NDK）将api密钥隐藏在移动应用程序代码中，但它不会阻止某人执行MITM攻击以窃取api密钥。实际上，MITM攻击很容易被非开发人员实现。

我要告诉你，没有希望保护的API服务器从存在什么访问它？好吧，我不是...

可能的解决方案

如何保护API密钥？

移动应用程序只能与您所控制的API服务器通信，并且对第三方API服务的任何访问都必须由您控制的同一API服务器完成。

通过这种方式，您可以将攻击面限制在一个地方，在那里您将采用防御所需要保护的多层防御。

根据您要保护的API密钥后面的值，您可能希望使用Web应用程序防火墙（WAF），并且如果可以负担得起的话，可以使用用户行为分析（UBA）解决方案。

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服务器保证可以信任请求而不会出现误报。

移动应用证明

移动应用程序证明服务的作用是在运行时通过在后台运行将与云中运行的服务进行通信的SDK来确保您的移动应用程序未被篡改或不在根设备中运行，以确保移动应用程序和设备的完整性正在运行。

在成功证明移动应用程序完整性后，将发布并签名一个短时生存的JWT令牌，并秘密告知只有云服务器中的API服务器和移动应用程序证明服务。在移动应用证明失败的情况下，将使用API​​服务器不知道的秘密对JWT令牌进行签名。

现在，应用程序必须与每个API一起发送，并在请求的标头中调用JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求，而在验证失败时拒绝请求。

一旦移动应用程序不知道移动应用程序证明服务使用的机密，就无法在运行时对其进行反向工程，即使该应用程序被篡改，在有根设备中运行或通过正在作为连接的连接进行通信中间攻击中一名男子的目标。

移动应用证明服务已经作为Approov的SAAS解决方案存在（我在这里工作），该服务提供了多个平台的SDK，包括iOS，Android，React Native等。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。API服务器必须能够执行此检查，才能决定服务哪些请求以及拒绝哪些请求。

结论

最后，必须根据要保护的内容的价值以及该类型数据的法律要求（例如欧洲的GDPR法规）来选择用于保护API服务器的解决方案。

因此，使用API​​钥匙听起来就像锁上了房屋的门，将钥匙留在了垫子下面，但不使用它们就像是在门关闭的情况下将车停在停车场，而钥匙却在点火。

Answer 2

这个问题通常是如何解决的？

（听起来您试图保护的 API 密钥适用于您不拥有的 API 服务。）

一种方法是使用身份验证服务器。私有 API 密钥保存在身份验证服务器上，仅在有效登录后共享。

那么这是如何运作的呢？

• 用户在移动客户端输入登录名和密码
• 这些凭证被发送到身份验证服务器并在其中进行验证
• 如果登录有效，API-key 将发送到移动客户端

从架构上讲，您需要一个单独的身份验证服务器，这将为您留下两个不同的服务器：

1. 一些需要私有 API 密钥才能使用的 API 密钥服务器

2. 身份验证服务器（用于验证用户登录并交换私有 API 密钥）

第二种方法是使用直通服务器。在这种方法中，私有 API 密钥永远不会共享。可以将身份验证添加到直通服务器上，但这不是必需的。

那么这是如何运作的呢？

• 移动用户联系传递服务器以获取来自 API 的数据
• 直通服务器进行 api 调用（使用存储的私有 API 密钥）
• API 服务器向 pass-thru 服务器响应数据
• 直通服务器将 API 响应转发到移动应用程序

在这种情况下，您拥有直通服务器，因此您永远不需要共享 API 密钥，并且用户身份验证是可选的。