使用移动应用使用的终结点保护 API

Protect API with endpoint used by mobile apps

提问人:Shant Hagopian 提问时间:5/5/2023 更新时间:5/8/2023 访问量:193

问:

我正在使用 .netcore API 和 Xamarin 移动应用,无需用户身份验证(无需登录)

我有几个 API 终结点,我希望仅允许某些应用(如 Xamarin 移动应用或具有机密 API 密钥的应用)能够调用该终结点。

显然,使用这种方法,我必须在移动应用程序中发布此秘密API密钥,我认为这是一个安全问题,因为有人可以对.apk进行逆向工程并提取API密钥。

对于托管在 Azure 上的 Web 应用,可以选择将 API 密钥存储在 keyvault 中,甚至可以作为应用程序配置存储,但移动应用没有这种奢侈。

有没有更好的方法可以专门使用移动应用程序来做到这一点?

API 安全性 xamarin .net-core

评论


答:

1赞 Exadra37 5/8/2023 #1

逆向工程

我有几个 API 终结点,我希望仅允许某些应用(如 Xamarin 移动应用或具有机密 API 密钥的应用)能够调用该终结点。

显然,使用这种方法,我必须在移动应用程序中发布此秘密API密钥,我认为这是一个安全问题,因为有人可以对.apk进行逆向工程并提取API密钥。

你是对的。在移动应用程序代码中拥有 API 密钥并不能保护它不被静态二进制分析提取,并且存在许多开源工具来使其成为一项简单的任务。此外,如果攻击者无法通过静态分析提取它,那么他们可以诉诸运行时攻击,他们可以在运行时执行 MitM 攻击和/或使用检测框架挂钩到代码中。

静态分析

我的首选工具是 MobSF(移动安全框架),我在如何使用静态二进制分析从移动应用程序中提取 API 密钥一文中展示了使用此工具提取 API 密钥是多么容易:

可用于逆向工程的开源工具范围非常广泛,我们真的无法在本文中触及这个主题的表面,而是我们将专注于使用移动安全框架(MobSF)来演示如何对移动应用程序的APK进行逆向工程。MobSF 是开源工具的集合,这些工具在有吸引力的仪表板中显示其结果,但在 MobSF 和其他地方使用的相同工具可以单独使用以实现相同的结果。

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

如果有人用来解码移动应用程序二进制文件,那么他们只需使用 Linux 和/或命令即可在移动应用程序中查找机密。apktoolgrepstring

运行时攻击和检测框架

当攻击者没有成功或不想花时间进行静态二进制分析时,MitM 攻击是合乎逻辑的选择,可能需要或不需要使用检测框架。例如,如果使用证书固定,则攻击者需要使用检测框架绕过它才能执行 MitM 攻击,正如我在如何在 Android 应用程序上使用 Frida 绕过证书固定一文中所示:

今天,我将展示如何使用 Frida 检测框架在运行时挂接到移动应用程序并检测代码,以便即使移动应用程序已实现证书固定,也能成功执行 MitM 攻击。

绕过证书固定并不太难,只是有点费力,并且允许攻击者详细了解移动应用程序如何与其 API 通信,然后使用相同的知识来自动执行攻击或围绕它构建其他服务。

可能的解决方案

代码混淆

请记住,有些人可能会建议使用代码混淆,但代码混淆只会混淆将硬编码 API 密钥的变量名称和/或返回它的方法名称,将 API 密钥以纯文本形式保留在移动设备中安装的移动应用程序二进制文件上。当代码混淆被用来隐藏秘密时,它会在安全防御中引入马其诺防线,一种虚假的安全感。对这个类比感到好奇,请阅读我的博客文章代码混淆值得吗?

正如一位开发人员曾经说过的那样......这要视情况而定!!

In a nutshell, it depends on what is motivating you to use obfuscation in the first place. If you plan to use only code obfuscation as a security measure then you may end up with a Maginot Line on your security defences.

In this article, we will first provide a brief lesson on World War II to understand how the French's impenetrable fortifications built to prevent invasion by Germany were easily circumvented. We will use this as an analogy to understand how attackers can do the same when they encounter code obfuscation being used as a technique to hide hardcoded secrets in a mobile app.

Sure, one can add code/hardening/encryption to make it harder for attackers to perform code static analysis on the binary, but that will not stop the more skilled attackers or the ones with time to invest on breaking it, but as In the Maginot Line, a smart attacker just goes around it and performs a MitM attack.

Runtime Secrets

A best approach is to not have secrets on the mobile app binary and retrieve them at runtime.

A technique that I have seen being used involves retrieving secrets when the mobile app is first booted, after installation, or every-time is launched, but this means TOFU (Trust on First Usage), which an attacker can exploit to also grab those secrets.

To avoid TOFU I will recommend you to read my accepted answer to the question How to use an API from my mobile app without someone stealing the token where the Runtime Secrets Protection seems your best option.

In a nutshell you will have the secret stored in the cloud and have it delivered just-in-time of being used to your mobile app, but only if the same is not being under attack, running on a root or jaill broken device, isn't attached to a debugger or running in an emulator, which uses remote mobile app attestation to decide about the device and app integrity, not in-app decisions.

Do You Want To Go The Extra Mile?

In any response to a security question I always like to reference the excellent work from the OWASP foundation.

For APIS

OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

For Web Apps

The Web Security Testing Guide:

The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.

评论

1赞 Shant Hagopian 5/15/2023
Appreciate the details and all the effort you put into this answer.
0赞 Stoycho Andreev 12/7/2023
Great short-long answer :)