避免本地移动应用程序中的网络钓鱼攻击

Question

我目前正在设计一个本机应用程序，它将有一个简单的用户名/密码登录。 在有效的身份验证中，后端服务器发出 JWT 访问令牌和刷新令牌，最终在随后的 API 调用中使用它们。

我担心的是，使用这种方法，我的应用程序很容易受到网络钓鱼攻击，黑客可以使用恶意拦截器反编译和重新编译我的应用程序。

为了克服这个问题，我正在考虑设计我的登录 API，以便在refreshToken的有效负载响应中没有accessToken和 refreshToken，登录 API 将发出重定向问题myapp://some-path?accessToken=X&refreshToken=Y 3013A14FZ myapp://some-path?accessToken=X&refreshToken=Y 。 这将确保如果网络钓鱼应用程序正在调用我的 API，则将accessToken和refreshToken发送到原始 APP。

这是一个正确的方法吗？ 如果没有，会建议哪种设计？

Answer 1

那会有什么帮助？ 如果我要进入您的应用程序进行破解和重新编译，我将接管整个应用程序。 我不会留下旧版本的副本，我只是要替换网址。 因此，当您重定向到 myapp://somepath 时，它将重定向到同一个被黑的应用程序。

其次，重定向将如何做任何事情？ 发出 HTTP 请求不会导致应用程序在客户端上启动。 它会导致 HTTP 请求返回 HTTPResponse object，响应代码为 301。因此无论如何您的重定向 URL 都不会启动。

第三，为时已晚。 当您拥有访问和刷新令牌时，您已经登录。这意味着被黑客入侵的应用程序拥有您的密码和凭据。 2FA 在这里可能会有所帮助，使其更难攻击，但前提是它基于时间，即使这样，它也只会减少 window。

如果用户正在安装您的应用程序的黑客版本并愿意登录，那么您已经迷路了。

Answer 2

你的问题

我目前正在设计一个本机应用程序，它将有一个简单的用户名/密码登录。 在有效的身份验证中，后端服务器发出 JWT 访问令牌和刷新令牌，最终在随后的 API 调用中使用它们。

您需要记住，离开后端或存储在移动应用程序中的任何秘密都不再是秘密，而是公开的东西，即使您使用 TLS（在某些情况下可能被截获）和证书固定（在某些情况下可以绕过），因为攻击者可以通过大量开源工具和技术对您的移动应用程序进行逆向工程，其中之一是您提到的 static 反编译：

我担心的是，使用这种方法，我的应用程序很容易受到网络钓鱼攻击，黑客可以使用恶意拦截器反编译和重新编译我的应用程序。

一旦它被反编译，攻击者就可以对你的代码做任何他想做的事，而不仅仅是添加拦截器。 众所周知，Google Play 商店充满了克隆和重新打包的应用程序，这些应用程序将使用与正版应用程序相同的后端。 你甚至有一个 repo RePack: A repository of repackaged Android apps ，这说明了问题：

RePack 是从 AndroZoo 收集的超过 15,000 个重新打包的 Android 应用程序对的存储库。 应用程序的 SHA256 可在 repackaging_pairs.txt 文件中找到。 实际的 APK 在 AndroZoo 数据集中可用，可以通过提供 SHA256 作为输入来下载。 请关注此页面以了解如何从 AndroZoo 下载应用程序。

重新打包后，这些应用程序可用于简单地添加广告并充当您的服务的假应用程序，其中利润将 go 给攻击者，或可用于分发恶意软件和/或监视用户，如文章700,000所示去年在 Google Play 商店中发现的恶意 Android 应用程序：

谷歌已经确认，它必须在 2017 年从 Google Play 商店中删除近 700,000 个潜在恶意应用程序——比上一年增加了 70%。

逆向工程

事实是，在客户端运行的任何东西都可以很容易地被攻击者在他控制的设备上进行逆向工程。

When reverse engineering a mobile app an attacker first step may be to perform a static binary analysis to extract all static secrets and to identify attack vectors, and you can see how in my article How to Extract an API key from a Mobile App with Static Binary分析：

可用于逆向工程的开源工具范围很广，我们真的无法在本文中触及这个主题的表面，而是将重点放在使用移动安全框架 (MobSF)来演示如何逆向工程我们的移动应用程序的 APK。 MobSF 是一组开源工具，它们在一个有吸引力的仪表板中显示其结果，但在 MobSF 和其他地方使用的相同工具可以单独使用以实现相同的结果。

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

提取机密的另一种方法是执行中间人 (MitM) 攻击以拦截 TLS 连接并提取所有机密并了解移动应用程序如何与后端和任何其他第三方 API 交互，您可以看到我是怎么做的它在文章Steal that Api Key with a Man in the Middle Attack 中：

In order to help to demonstrate how to steal an API key, I have built and released in Github the Currency Converter Demo app for Android, which uses the same JNI/NDK technique we used in the earlier Android Hide Secrets app to hide the API key .

因此，在本文中，您将学习如何在您控制的移动设备中设置和运行中间人攻击以拦截 https 流量，从而窃取 API 密钥。 最后，您将了解如何缓解中间人攻击。

等等，我想你现在在想，但我将使用证书固定来保护我的 TLS 通道，没问题只需在绕过证书固定一文中查看如何在攻击者控制的设备中轻松绕过证书固定

在本文中，您将学习如何重新打包移动应用程序以禁用证书固定，并且在此过程中，您还将学习如何创建具有可写系统的 Android 模拟器，以允许将代理服务器的自定义证书颁发机构添加到Android 操作系统信任存储。 这将允许我们绕过证书锁定并通过中间人攻击拦截移动设备与其后端之间的请求。

虽然重新打包移动应用程序以绕过固定是一个很好的解决方案，但我更喜欢在运行时动态地执行它，正如我在如何在 Android 应用程序上使用 Frida 绕过证书固定一文中所示：

今天我将展示如何使用 Frida 检测框架在运行时挂钩到移动应用程序并检测代码以执行成功的中间人攻击，即使移动应用程序已经实现了证书锁定。

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

现在您可能会认为您已经输掉了这场战斗，不应该关心添加保护，因为它们最终会被绕过。 好吧，我必须告诉你，软件安全与中世纪城堡中的防御具有相同的特征，他们分层使用它，以使对城堡的攻击尽可能困难，希望是不可能的。 因此，您需要采取与他们相同的姿态，并根据法律要求设置尽可能多的安全层，以使攻击者的工作变得耗时并需要比大多数人可能拥有的更多专业知识。

你的问题

为了克服这个问题，我正在考虑设计我的登录 API，以便在 API 的有效负载响应中没有 accessToken 和 refreshToken，登录 API 将发出重定向问题：//路径 3013A14FZ访问令牌=X&刷新令牌=Y。 这将确保如果网络钓鱼应用程序正在调用我的 API，则将 accessToken 和 refreshToken 发送到原始 APP。

这是一个正确的方法吗？

因此，我认为现在很明显，您的解决方案不会有效，并且很容易通过重新打包移动应用程序、MitM 攻击它或仅通过在运行时检测代码来击败它。

如果没有，会建议哪种设计？

您应该使用一种安全方法，其中 API 后端能够识别发出请求的确实是您的移动应用程序的真实且未篡改/重新打包/克隆的版本，而不仅仅是发出请求的人，因为用户身份验证仅是用于保护对 API 的未经授权的访问。

WHO和WHAT访问API服务器的区别

我围绕 API 和移动安全写了一系列文章，并在文章为什么您的移动应用程序需要 Api 密钥？ 您可以详细阅读访问您的 API 服务器的人员和对象之间的区别，但我将在这里提取主要内容：

向 API 服务器发出请求的原因是什么。 它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动在您的 API 服务器周围进行攻击？

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

因此，请考虑谁是您的 API 服务器将能够验证和授权对数据的访问的用户，并考虑代表用户发出请求的软件是什么。

可能的解决方案

我建议您阅读我对如何保护移动应用程序的 API REST问题给出的答案？ ，尤其是强化和屏蔽移动应用程序、保护 API 服务器和可能更好的解决方案等部分。

您将看到您可以使用过多的防御层，例如在中世纪城堡中，并且您可能想要采用的解决方案可以高度自信地保证向后端发出请求的确实是您真正的手机app，是移动应用认证。

您想要额外的里程吗？

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

对于 APIS

OWASP API 安全前 10 名

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

对于移动应用

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

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

OWASP - 移动安全测试指南：

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