我目前正在设计一个本机应用程序，该应用程序将具有简单的用户名/密码登录。在有效的身份验证中，后端服务器会发出 JWT 访问令牌和刷新令牌，这些令牌最终会在后续 API 调用中使用。
我担心的是，使用这种方法，我的应用很容易受到网络钓鱼攻击，黑客可以使用恶意拦截器反编译和重新编译我的应用。
为了克服这个问题，我正在考虑设计我的登录 API，以便在 API 的有效负载响应中不包含 accessToken 和 refreshToken，登录 API 将在 @ 上发出 301 重定向987654323@。这将确保如果钓鱼应用正在调用我的 API，accessToken 和 refreshToken 将被发送到原始 APP。
这是正确的方法吗？如果没有，会建议哪种设计？
【问题讨论】：
标签： android ios authentication oauth-2.0 jwt
这有什么帮助？如果我要进入你的应用程序进行破解和重新编译，我将接管整个应用程序。我不会留下旧版本的副本，我只是要替换网址。所以当你重定向到 myapp://somepath 时，它会重定向到同一个被黑的应用程序。
其次，重定向将如何做任何事情？发出 HTTP 请求不会导致应用程序在客户端上启动。它会导致 HTTP 请求返回一个响应代码为 301 的 HTTPResponse 对象。因此无论如何您的重定向 URL 都不会启动。
第三，已经太晚了。当您拥有访问和刷新令牌时，您已经登录。这意味着被黑客入侵的应用程序拥有您的密码和凭据。 2FA 在这里可能会有所帮助，使其更难攻击，但前提是它基于时间，即使这样它也只是减少了窗口。
如果用户正在安装您的应用的黑客版本并愿意登录，那么您已经迷路了。
【讨论】：
我目前正在设计一个本机应用程序，该应用程序将具有简单的用户名/密码登录。在有效的身份验证中，后端服务器会发出 JWT 访问令牌和刷新令牌，这些令牌最终会在后续 API 调用中使用。
您需要记住，任何离开后端或存储在移动应用程序中的秘密都不再是秘密，而是公开的东西，即使您使用的是 TLS（在某些情况下可能被截获）并且证书固定（在某些情况下可以绕过），因为攻击者可以通过大量开源工具和技术对您的移动应用程序进行逆向工程，其中之一是您提到的静态反编译：
我担心的是，使用这种方法，我的应用很容易受到网络钓鱼攻击，黑客可以使用恶意拦截器反编译和重新编译我的应用。
一旦它被反编译，攻击者就可以对你的代码做任何他想做的事，而不仅仅是添加拦截器。众所周知，Google Play 商店充满了cloned 和重新打包的应用程序，这些应用程序将使用与正版应用程序相同的后端。你甚至有一个 repo RePack: A repository of repackaged Android apps，这说明了问题：
RePack 是从 AndroZoo 收集的 15,000 多个重新打包的 Android 应用程序对的存储库。应用程序的 SHA256 可在 repackaging_pairs.txt 文件中找到。实际的 APK 在 AndroZoo 数据集中可用，可以通过提供 SHA256 作为输入来下载。请关注此页面以了解如何从 AndroZoo 下载应用程序。
重新打包后，这些应用程序可用于简单地添加广告并充当您服务的假应用程序，利润将流向攻击者，或者可用于分发恶意软件和/或监视用户，如文章700,000 malicious Android apps found in Google Play store last year：
Google 已确认，它必须在 2017 年从 Google Play 商店中删除近 700,000 个潜在恶意应用，比上一年增加了 70%。
事实上，在客户端运行的任何东西都可以被逆向工程 攻击者很容易在他控制的设备上被攻击。
在对移动应用程序进行逆向工程时，攻击者的第一步可能是执行静态二进制分析以提取所有静态机密并识别攻击向量，您可以在我的文章中了解具体方法 How to Extract an API key from a Mobile App with Static Binary Analysis:
可用于逆向工程的开源工具范围很广，我们在本文中确实无法触及这个主题的表面，而是我们将重点使用Mobile Security Framework(MobSF) 来演示如何逆向工程我们的移动应用程序的 APK。 MobSF 是一组开源工具，它们在一个有吸引力的仪表板中展示其结果，但在 MobSF 和其他地方使用的相同工具可以单独使用以实现相同的结果。
在本文中，我们将使用 Android Hide Secrets 研究存储库，它是一个虚拟移动应用程序，使用多种不同技术隐藏了 API 密钥。
提取机密的另一种方法是执行中间人 (MitM) 攻击以拦截 TLS 连接并提取所有机密并了解移动应用如何与后端和任何其他第三方 API 交互，您可以看到我在文章中是如何做到的 Steal that Api Key with a Man in the Middle Attack:
为了帮助演示如何窃取 API 密钥，我在 Github 中构建并发布了适用于 Android 的 Currency Converter Demo 应用程序，它使用了我们在之前的 Android Hide Secrets 应用程序中使用的相同 JNI/NDK 技术来@ 987654331@.
因此，在本文中，您将学习如何设置和运行中间人攻击，以拦截您控制的移动设备中的 https 流量，从而窃取 API 密钥。最后，您将了解如何缓解中间人攻击。
等等，我想你现在在想，但我将使用证书固定来保护我的 TLS 通道，没问题，只需在文章 Bypassing Certificate Pinning 中查看如何在攻击者控制的设备中轻松绕过证书固定即可
在本文中，您将学习如何重新打包移动应用程序以禁用证书固定，并且在此过程中，您还将学习如何创建具有可写系统的 Android 模拟器，以允许为代理添加自定义证书颁发机构服务器进入 Android 操作系统信任库。这将允许我们绕过证书锁定并通过中间人攻击拦截移动设备与其后端之间的请求。
虽然重新打包移动应用程序以绕过固定是一个很好的解决方案，但我更喜欢在运行时动态地执行此操作，正如我在文章 How to Bypass Certificate Pinning with Frida on an Android App 中所展示的那样：
今天我将展示如何使用 Frida 检测框架在运行时挂钩到移动应用程序并检测代码以执行成功的中间人攻击，即使移动应用程序已经实现了证书锁定。
绕过证书固定并不太难，只是有点费力，并且允许攻击者详细了解移动应用程序如何与其 API 通信，然后使用相同的知识来自动化攻击或围绕它构建其他服务。
现在您可能会认为您已经输掉了战斗，不应该关心添加保护，因为它们最终会被绕过。好吧，我必须告诉你，软件安全与中世纪城堡中的防御具有相同的特征，他们分层使用它，以使对城堡的攻击尽可能困难，希望是不可能的。因此，您需要采取与他们相同的姿态，并根据法律要求设置尽可能多的安全层，以使攻击者的工作变得耗时并需要比大多数人可能拥有的更多专业知识。
为了克服这个问题，我正在考虑设计我的登录 API，这样登录 API 将在 myapp://some 上发出 301 重定向，而不是在 API 的有效负载响应中包含 accessToken 和 refreshToken -path?accessToken=X&refreshToken=Y。这将确保如果钓鱼应用正在调用我的 API，则将 accessToken 和 refreshToken 发送到原始 APP。
这是一个正确的方法吗？
因此，我认为现在很明显，您的解决方案不会有效，并且很容易通过重新打包移动应用程序、MitM 攻击它或仅通过在运行时检测代码来击败它。
如果没有，建议采用哪种设计？
您应该使用一种安全方法，让 API 后端能够识别 什么 发出请求确实是您的移动应用程序的真实且未篡改/重新打包/克隆版本，而不仅仅是 谁发出请求，因为用户身份验证仅用于保护对 API 的未经授权的访问。
我写了一系列关于 API 和移动安全的文章，在文章 Why Does Your Mobile App Need An Api Key? 你可以详细阅读 谁 和 what 访问你的API 服务器，但我将在这里提取它的主要内容：
what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？
谁是移动应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。
因此，将 谁 视为您的 API 服务器将能够对数据进行身份验证和授权访问的用户，并将 what 视为制作该数据的软件代表用户请求。
我建议您阅读 this answer 我提出的问题如何保护移动应用程序的 API REST？，尤其是强化和屏蔽移动应用程序部分 ，保护 API 服务器和可能更好的解决方案。
您将看到您可以使用过多的防御层，例如在中世纪城堡中，以及您可能想要采用的解决方案，以高度自信地保证什么正在做对后端的请求确实是你的正版移动应用，是移动应用证明。
在回答安全问题时，我总是喜欢参考 OWASP 基金会的出色工作。
OWASP API 安全项目旨在通过强调不安全 API 的潜在风险并说明如何降低这些风险，为软件开发人员和安全评估人员提供价值。为了实现这一目标，OWASP API 安全项目将创建和维护一份 API 安全风险前 10 名文档，以及一个文档门户，用于在创建或评估 API 时提供最佳实践。
OWASP Mobile Security Project - Top 10 risks
OWASP 移动安全项目是一个集中资源，旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目，我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。
OWASP - Mobile Security Testing Guide:
移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
【讨论】：