应用错误收集

授权令牌

如果我有用于身份验证的令牌。

请记住，用户身份验证令牌仅标识谁在请求中，而不标识做什么在执行请求。如果您还没有意识到这一点，请不要担心，因为这是任何级别和背景的开发人员都很常见的误解。

所以让我们先清除它...

我写了一系列有关API和移动安全的文章，在文章Why Does Your Mobile App Need An Api Key?中，您可以详细了解谁和什么之间的区别正在访问您的API服务器，但我会引用其中的一些要点：

什么是向API服务器发出请求的东西。它确实是您的移动应用程序的真实实例，还是机器人，自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛？

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

因此，请考虑谁，您的API服务器将能够对用户进行身份验证和授权访问数据，并考虑什么作为使该数据访问的软件代表用户的请求。

如果我有用于身份验证的令牌。然后，即使我在应用程序内对令牌进行哈希处理并将其发送到服务器，然后应用程序的用户也可以轻松捕获POST请求并找到令牌，然后将其与数据库用户的哈希令牌进行比较，仍然可以捕获哈希令牌...

无论您最终使用哪种技术，攻击者始终可以掌握您试图向他隐瞒的任何秘密，但问题是，他愿意付出多大的努力才能从移动应用程序和/或他执行这些任务需要多少知识。

如今，我们拥有大量工具来帮助安全研究人员或任何有恶意的人对移动应用进行反向工程，例如：

对于MitM攻击-mitmproxy

面向渗透测试人员和软件开发人员的交互式TLS拦截HTTP代理。

Mobile Security Framework是一个自动化的多合一移动应用程序（Android / iOS / Windows）笔测试框架，能够执行静态分析，动态分析，恶意软件分析和Web API测试。

对于运行时代码检测-Frida

将您自己的脚本注入黑盒进程。挂钩任何功能，监视加密API或跟踪私有应用程序代码，不需要任何源代码。编辑，点击保存，立即查看结果。全部没有编译步骤或程序重新启动。

尽管存在这种工具，但我仍然鼓励您在移动应用程序中使用尽可能多的防御技术，因为并不是每个攻击者都了解或愿意在移动应用程序中花费太多时间，因为他们更容易攻击目标。

解决这个问题的真正方法是什么？

不存在true的方式，这全都取决于您的特殊用例，以及您有多少，可以负担得起的资源以及法律要求这样做的资源。

对于服务于移动应用程序的API，您可以采用“移动应用程序证明”概念，这将使您的API服务器对正在做什么向API服务器发出请求具有高度的信心。真正且不受干扰的移动应用程序，或者是攻击者。

我建议您阅读this answer，我提到的问题是如何保护移动应用程序的API REST？，尤其是保护API服务器部分和更好的解决方案。

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

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

移动安全测试指南（MSTG）是用于移动应用安全开发，测试和逆向工程的综合手册。

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