【问题标题】:Ways for verify mobile application client on server在服务器上验证移动应用程序客户端的方法
【发布时间】:2021-03-28 07:13:35
【问题描述】:

我正在寻找一种设计方式

移动应用程序服务器API:

  • 授权用户和应用使用 OAuth2.0 使用服务器
  • 在服务器上验证它是合法的应用程序

我现在面临的问题:Oauth2.0 术语中的应用是一个公共客户端: 无法保护应用程序包中的任何静态信息 - 任何人都可以提取此类信息并在假应用程序中重复使用。

如果我添加一些额外的方法来在服务器上注册新的应用程序实例 - 没有什么可以阻止假应用程序做同样的事情。

是否有任何方法可以在不涉及 REST API 的情况下在应用程序和服务器之间交换数据,或者获取有关调用应用程序的经过验证的信息。

我知道答案是特定于平台的 - 我对任何平台上的信息都很感兴趣,因为我可以搜索其他平台上的类似信息。

【问题讨论】:

    标签: security mobile oauth-2.0


    【解决方案1】:

    对于移动应用,请使用授权代码流 (PKCE),它会生成运行时密码,因此无需为应用部署固定密码。

    流氓应用可能会使用您应用的客户端 ID 和重定向 URI,但处理这种情况的一种方法是使用 声称的基于 HTTPS 方案的重定向,正如 Financial Grade APIs / Native Apps 中所推荐的那样。

    如果对这种方法感兴趣,我的博客有几个详细示例:

    【讨论】:

    • 感谢您的想法,但 PKCE 不验证公共应用程序。只是去掉了固定的秘密,但假应用程序钢可以使用真实应用程序的client_id。
    • 如果您使用声称的 HTTPS 方案重定向,那么尝试使用您的客户端 ID 的应用将无法接收登录响应 - 我已经更新了上面的原始答案(和链接)。
    • 感谢您的澄清,我们将寻找声称的 HTTPS 方案
    【解决方案2】:

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

    我正在寻找一种设计方式

    移动APP 服务器API:

    • 授权用户和应用使用 OAuth2.0 与服务器合作WHO
    • 在服务器上验证它是合法的应用程序什么

    在深入探讨您的问题之前,我想先澄清一个我通常在任何资历的开发人员中发现的误解,那就是what之间的区别正在访问 API 服务器

    我写了一系列关于 API 和移动安全的文章,在文章 Why Does Your Mobile App Need An Api Key? 你可以详细阅读 what 访问你的API 服务器,但我将在这里提取它的主要内容:

    what 是向 API 服务器发出请求的事物。它真的是您的移动应用程序的真实实例,还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器?

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

    视为您的 API 服务器将能够对数据进行身份验证和授权访问的用户,并将什么视为发出该请求的软件代表用户。

    因此,您需要记住,您知道在请求中的保证并不能保证您的请求确实来自您的 API 服务器所期望的什么 ,您的移动应用的正版且未经修改的版本。

    可能的解决方案

    如果我添加一些额外的方法来在服务器上注册新的应用程序实例 - 没有什么可以阻止假应用程序做同样的事情。

    是否有任何方法可以在不涉及 REST API 的情况下在应用程序和服务器之间交换数据,或者获取有关调用应用程序的经过验证的信息。

    如果您的 API 服务器可以高度确信请求确实来自它所期望的什么,那么您的移动应用程序的真实且未经修改的版本,然后注册应用程序的新实例并交换API 服务器的数据可以在不涉及不良行为者的情况下完成。

    您可以借助 UBA 和 RASP 解决方案来帮助您了解 什么 正在发出 API 请求:

    UBA - User Behavior Analytics:

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

    RASP:

    运行时应用程序自我保护 (RASP) 是一种安全技术,它使用运行时工具通过利用运行软件内部的信息来检测和阻止计算机攻击。

    据说 RASP 技术通过监控其输入并阻止可能允许攻击的输入来提高软件的安全性,同时保护运行时环境免受不必要的更改和篡改。

    UBA 基于负面识别模型,该模型通过识别什么是坏的而不是什么是好的,尽最大努力区分好坏,因此它们容易出现误报。 UBA 解决方案基于分析每个 API 请求,他们没有从移动应用程序及其设备上发生的事情中收集客户端实时情报。

    RASP 解决方案是客户端,API 服务器无法查看它们检测和阻止的内容。一旦它们是客户端,它们就可以在 API 服务器不知道发生的情况下被绕过,因此它将接受来自此绕过的 API 请求。

    我建议您阅读this answer 我提出的问题如何保护移动应用程序的 API REST?,尤其是强化和屏蔽移动应用程序部分保护 API 服务器可能更好的解决方案

    因此,链接答案中可能更好的解决方案部分提到了使用移动应用程序证明解决方案,该解决方案将结合云服务和移动应用程序之间的实时后台通信来证明移动应用程序是真实且未经修改的,即在受信任的设备中运行。然后,API 服务器将能够非常有把握地知道发出请求的什么确实是在受信任设备上运行的移动应用程序的真实且未经修改的版本。

    你想加倍努力吗?

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

    对于 APIS

    OWASP API Security Top 10

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

    对于移动应用

    OWASP Mobile Security Project - Top 10 risks

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

    OWASP - Mobile Security Testing Guide:

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

    【讨论】:

      猜你喜欢
      • 2011-09-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2010-11-20
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多