如何识别调用API端点的应用程序或网站？

Question

我们正在做一个APIin PHP. 我们希望API端点仅由某些指定的应用程序和网站调用（不通过Postman或任何类似软件）。我们尝试通过调用发送一些身份验证密钥，但有些工具甚至可以从signed APK（在 WhatsApp 的 apk 上测试）获取整个代码，因此密钥可能会泄露。

因此，我们试图弄清楚是否有一种方法可以识别调用者应用程序或网站，API endpoint然后我们将验证身份PHP并提供response相应的信息。

有什么办法可以实现这一点吗？如果没有，那么还有其他解决办法吗？

提前致谢。

Answer 1

挑战

\n

\n

我们希望 API 端点仅由某些指定的应用程序和网站调用（不通过 Postman 或任何类似软件）。

\n

\n

好吧，你给自己带来了一个巨大的挑战，而且是一个需要深思熟虑解决的挑战。

\n

在深入研究细节之前，我可以说，保护仅服务于移动应用程序的 API 比保护同时服务于移动应用程序和 Web 应用程序的 API 更容易。

\n

作为剧透警告，我可以说，对于 Web 应用程序，API 服务器最好的机会是使用人工智能来防御非真实请求，而对于移动应用程序，当 API 服务器能够证明时，解决方案更加有效和简单执行请求的移动应用程序是真实且未经修改的。

\n

逆向工程

\n

网络构建方式的本质使得在客户端内省代码变得非常容易，也就是说你只需要点击F12或右键单击即可查看页面的页面源代码，从而轻松地对任何自我防御代码进行逆向工程或将用于识别应用程序的任何秘密提取到 API 服务器。

\n

对于移动应用程序来说，这不是那么容易，但也不是那么难，因为我们有优秀的开源工具来帮助我们做到这一点，例如移动安全框架（MoBSF），它在一个 Web 界面下聚合了多个工具，这将使逆向工程和提取签名 APK 的源代码和秘密变得轻而易举，就像您使用 What\'s App 所实现的那样：

\n

We have tried to send some authentication key with the call but there are tools which can be used to get the entire code even from a signed APK(tested on the apk of whatsApp), so the key could get leaked. \n

\n

正如我在本文中所示，移动应用程序中的秘密很难通过静态二进制分析来提取：

\n

\n

在本文中，我们将使用Android Hide Secrets研究存储库，它是一个虚拟移动应用程序，使用多种不同的技术隐藏 API 密钥。

\n

\n

上面的文章展示了如何使用本机JNI/NDK接口隐藏C代码中的秘密，从而使其很难提取，但是你不能通过静态分析来做到这一点，你可以通过MiTM 代理攻击动态地做到这一点，正如我在另一篇文章中所描述的：

\n

\n

\n

为了帮助演示如何窃取 API 密钥，我在 Github 上构建并发布了适用于 Android 的货币转换器演示应用程序，该应用程序使用我们在早期 Android Hide Secrets 应用程序中使用的相同 JNI/NDK 技术来隐藏 API 密钥。

\n

\n

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

\n

\n

因此，我们试图弄清楚是否有一种方法可以识别 API 端点的调用者应用程序或网站，然后我们将在 PHP 中验证身份并给出相应的响应。

\n

\n

因此，借助所有这些工具和对应用程序进行逆向工程的轻松访问，API 服务器区分请求中的人员和发出请求的内容变得非常具有挑战性，并且理解谁和什么之间的区别至关重要开发人员能够为其 API 服务器和应用程序定义安全策略。一旦这是一个经常被开发人员误解的概念，我建议您阅读我写的一篇文章的这一部分，其中更详细地解释了它，并从我引用的地方：

\n

\n

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

\n

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

\n

\n

因此，将“谁”视为您的 API 服务器将能够对数据进行身份验证和授权访问的用户，并将“什么”视为代表用户发出请求的软件，例如 Postman 或 cURL。

\n

消除了这种差异后，您现在可以更好地决定如何解决 API 服务器和应用程序的安全问题。

\n

识别请求中的人物和内容

\n

\n

有什么办法可以实现这一点吗？如果没有，那么还有其他解决办法吗？

\n

\n

要识别请求中的“谁”，您可以采用传统的身份验证和授权机制或使用OAuth2或OpenID Connect。

\n

识别请求中的内容是一项挑战，因为您的 API 服务器需要区分谁和内容，一些高级方法将使用用户行为分析 (UBA)来实现这一点。

\n

UBA 解决方案的一个示例是 [Google reCAPTCHA V3 ]，它不需要用户交互，并向 API 服务器给出请求来自人类的可能性的评分。

\n

虽然这会尽最大努力区分人类和机器，但它无法提供非常高的信心，保证您不会出现误报，但 UBA 的解决方案是您使用 API 的最佳机会为网络应用程序提供服务的服务器

\n

对于为移动应用程序提供服务的 API 服务器，我们可以利用移动应用程序证明概念来有效了解请求的内容，我建议您阅读我针对“如何确保 API REST 的安全”问题给出的答案移动应用？，这将建议您采用如下所示的最终解决方案：

\n

\n

阅读我链接的答案，了解移动应用程序证明如何从​​移动应用程序中删除机密，并让您的 API 服务器高度自信地了解请求的执行方式。

\n

您想加倍努力吗？

\n

在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。

\n

对于网络应用程序

\n

OWASP Web 十大风险

\n

\n

OWASP Top 10 是一份强大的 Web 应用程序安全意识文档。它代表了对 Web 应用程序最关键的安全风险的广泛共识。项目成员包括来自世界各地的多位安全专家，他们分享了自己的专业知识来制作此列表。

\n

\n

网络安全测试指南：

\n

\n

OWASP Web 安全测试指南包括用户可以在自己的组织中实施的“最佳实践”渗透测试框架和描述测试最常见 Web 应用程序和 Web 服务安全问题的技术的“低级”渗透测试指南。

\n

\n

对于移动应用程序

\n

OWASP 移动安全项目 - 十大风险

\n

\n

OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。

\n

\n

OWASP - 移动安全测试指南：

\n

\n

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

\n

\n

对于APIS

\n

OWASP API 安全性前 10 名

\n

\n

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

\n

\n

链接参考

\n

谷歌reCAPTCHA V3：

\n

\n

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

\n

...帮助您检测网站上的滥用流量，而不会造成任何用户摩擦。它会根据与您网站的交互返回一个分数，并为您提供更大的灵活性来采取适当的操作。

\n

\n

UBA - 用户行为分析：

\n

\n

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

\n

\n

移动安全框架

\n

\n

移动安全框架是一种自动化、一体式移动应用程序 (Android/iOS/Windows) 笔测试框架，能够执行静态分析、动态分析、恶意软件分析和 Web API 测试。

\n

\n

OAuth2

\n

\n

OAuth 2.0 是行业标准授权协议。OAuth 2.0 取代了 2006 年创建的原始 OAuth 协议上所做的工作。OAuth 2.0 注重客户端开发人员的简单性，同时为 Web 应用程序、桌面应用程序、移动电话和客厅设备提供特定的授权流程。该规范及其扩展正在IETF OAuth 工作组内开发内开发。

\n

\n

OpenID 连接

\n

\n

OpenID Connect 1.0 是 OAuth 2.0 协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终​​用户的基本配置文件信息。\nOpenID Connect 执行许多操作与 OpenID 2.0 相同的任务，但以 API 友好的方式执行，并且可由本机和移动应用程序使用。OpenID Connect 定义了用于稳健签名和加密的可选机制。尽管 OAuth 1.0a 和 OpenID 2.0 的集成需要扩展，但在 OpenID Connect 中，OAuth 2.0 功能与协议本身集成。

\n

\n

JNI/NDK：

\n

\n

使用 Android Studio 2.2 及更高版本，您可以使用 NDK 将 C 和 C++ 代码编译为本机库，并使用 IDE 的集成构建系统 Gradle 将其打包到 APK 中。然后，您的 Java 代码可以通过 Java 本机接口 (JNI) 框架调用本机库中的函数。

\n

\n