创建仅对电话有效的访问令牌（JWT）

Question

我在一个使用令牌（jwt）对移动应用程序中的用户进行身份验证的项目上工作。我想知道有一种方法，每个令牌仅对电话有效吗？例如，用户在应用程序中收到的令牌无法在邮递员或其他电话之类的软件中使用

Answer 1

基本上，您需要的是设备的唯一指纹。我建议使用此库Valve/fingerprintjs2。

一旦生成了设备唯一的指纹，就可以在令牌生成阶段将此指纹发送到身份验证服务器，以便可以将其用作生成JWT签名的盐。

最后，当设备将JWT发送回服务器进行身份验证时，它还必须发送自己的指纹。然后，服务器将使用该指纹来检查JWT签名。

由于该库生成的指纹对于每个设备都是唯一的，因此还可以确保仅将JWT应用于该设备。

编辑： @GaborLengyel我不想走那么远，因为我认为问题是要防止普通用户在多个设备上使用令牌。但是，正如您所问的那样，我建议使用在安装应用程序时为每个设备唯一提供的密码创建一个哈希生成器。哈希字符串必须基于以下条件生成和验证：

1. 上述独特的秘密。请注意，这个秘密也被用作生成JWT签名的盐
2. 从发送请求时算起的时间戳（定义这些时间戳的规则是在客户端上的哈希生成器和服务器上的哈希检查器之间预定义的，以便两者可以并行提供相同的时间戳而无需相互通信）

因此，为了保护Web服务，每个请求都必须通过此哈希生成器进行路由，在哈希生成器中，它将哈希字符串附加到请求标头，以便被Web服务器识别。然后，Web服务器计算出时间戳，在其秘密数据库中进行扫描，以查找与从客户端发送的哈希值匹配的时间戳。然后使用该秘密验证JWT。

在客户端发送请求并在服务器上接收请求时，带有相同时间戳的算法非常容易建立。例如：给定请求的超时时间是3秒，则可能是下一个时间戳（T），使得：T % 3 == 0在客户端和Web服务器上，匹配的时间戳是下一个或上一个时间戳，可以被3整除。

由于以这种方式生成的时间戳，每个令牌的生存时间都很短（在上述情况下为3s），因此无法在其他地方使用。我能想到的唯一方法是对哈希生成器进行反向工程并在其中找到秘密。

Answer 2

可以模拟任何请求。 这几乎是不可能的 您可以使用刷新令牌 减少您的令牌时间 如果有人到达访问权限，它们将很快过期

Answer 3

问题

  

我想知道每个令牌都仅对电话有效吗？例如，用户在应用程序中收到的令牌无法在邮递员或其他电话之类的软件中使用

嗯，您发现自己很难解决但并非不可能的问题。是的，在移动API的背景下可以解决该问题，该概念称为移动应用证明。

所以让我们分阶段研究您的问题...

  

我正在一个使用令牌（jwt）对移动应用程序中的用户进行身份验证的项目。

要在API服务器中对请求进行身份验证，您需要了解两件事，谁执行请求，什么执行请求，否则您将永远无法断言用户确实是人类，而不是其他人。

让我澄清一下有关 WHO 与什么正在访问您的API服务器的常见误解。

WHO和访问API服务器之间的区别

为了更好地了解 WHO 和 What 在访问API服务器之间的区别，让我们使用以下图片：

预期的通信渠道表示合法用户没有任何恶意意图就可以使用您期望的移动应用程序，它使用的是未修改版本的移动应用程序，并且可以直接与API服务器通信，而不会受到中间人的攻击。

实际渠道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用移动应用程序的重新打包版本，黑客使用了移动应用程序的真实版本，而中间人则在进行攻击，了解移动应用程序与API服务器之间的通信是如何进行的，以便能够自动对您的API进行攻击。可能还有许多其他情况，但是我们在这里不逐一列举。

我希望到现在为止您可能已经知道为什么 WHO 和 What 不同的地方，但是如果不一样的话，一会儿就会明白。

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

  

OAUTH

     

通常，OAuth代表资源所有者向客户端提供对服务器资源的“安全委派访问”。它为资源所有者指定了一个在不共享凭据的情况下授权第三方访问其服务器资源的过程。 OAuth专为与超文本传输​​协议（HTTP）配合使用而设计，实质上允许在资源所有者的批准下，授权服务器将访问令牌发布给第三方客户端。然后，第三方使用访问令牌访问资源服务器托管的受保护资源。

     

OpenID Connect

     

OpenID Connect 1.0是OAuth 2.0协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终​​用户的基本配置文件信息。

尽管用户身份验证可能会让API服务器知道 WHO 正在使用API​​，但不能保证请求源自您期望的 What 。移动应用。

现在，我们需要一种方法来识别正在调用的API服务器，这使得事情变得比大多数开发人员想象的要棘手。 内容是向API服务器发出请求的内容。它是移动应用程序的真正实例，还是使用诸如Postman之类的工具通过API服务器手动访问的机器人，自动脚本或攻击者？

让您感到惊讶的是，您可能最终发现它可能是使用重新打包的移动应用程序版本或试图游戏化并利用该应用程序提供的服务的自动脚本的合法用户之一。

好吧，为了确定内容，开发人员倾向于求助于通常会在其移动应用程序代码中进行硬编码的API密钥。一些开发人员花了很多功夫，并在移动应用程序中在运行时计算密钥，因此与将静态机密嵌入代码中的前一种方法相反，它成为了运行时机密。

以上文章摘录自我写的一篇文章，题为《 为什么您的移动应用程序需要API密钥？”，因此您可以完整阅读here，即有关API密钥的系列文章中的第一篇。

捍卫API服务器

根据您的预算和资源，您可以采用各种不同的方法和技术来保护您的API服务器，我将开始列举一些最常用的方法和技术，但是在我这样做之前，我想离开注意：

  

作为最佳实践，移动应用程序或Web应用程序应仅与您控制下的API服务器通信，并且对第三方API服务的任何访问都必须由您控制的同一API服务器来完成。通过这种方式，您可以将攻击面限制在一个地方，在那里您将采用防御所需要保护的多层防御系统。

您可以从reCaptcha V3开始，然后是Web Application Firewall（WAF），最后如果可以负担得起User Behavior Analytics（UBA）解决方案。

Google reCAPTCHA V3：

  

reCAPTCHA是一项免费服务，可保护您的网站免受垃圾邮件和滥用的侵害。 reCAPTCHA使用高级风险分析引擎和适应性挑战，以防止自动化软件参与您网站上的滥用行为。这样做是为了让您的有效用户轻松通过。

     

...可帮助您检测网站上的滥用流量，而不会引起用户的摩擦。它会根据与您网站的互动情况返回得分，并为您提供更大的灵活性以采取适当的措施。

WAF - Web Application Firewall：

  

Web应用程序防火墙（或WAF）过滤，监视和阻止与Web应用程序之间的HTTP通信。 WAF与常规防火墙的区别在于，WAF能够过滤特定Web应用程序的内容，而常规防火墙充当服务器之间的安全门。通过检查HTTP流量，它可以防止源自Web应用程序安全漏洞的攻击，例如SQL注入，跨站点脚本（XSS），文件包含和安全性错误配置。

UBA - User Behavior Analytics：

  

Gartner定义的用户行为分析（UBA）是一个有关检测内部威胁，针对性攻击和财务欺诈的网络安全流程。 UBA解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常，即表明潜在威胁的异常。 UBA不会跟踪设备或安全事件，而是跟踪系统的用户。像Apache Hadoop这样的大数据平台通过允许它们分析PB级的数据来检测内部威胁和高级持久威胁，正在增强UBA功能。

所有这些解决方案都基于否定性识别模型，换句话说，他们通过识别出什么是不好的而不是什么是好的来尽最大的努力将好与坏区别开来，因此尽管存在以下缺点，它们还是容易出现误报的情况其中一些人使用了先进的技术，例如机器学习和人工智能。

因此，您可能经常会发现自己不必放松放松如何阻止对API服务器的访问以不影响良好用户。这也意味着该解决方案需要进行持续监控，以验证误报不会阻止您的合法用户，同时又能正确阻止未经授权的用户。

关于为移动应用程序提供服务的API，可以通过使用移动应用程序证明解决方案来使用肯定的识别模型，该解决方案向API服务器保证可以信任请求，而不会产生误报。

更好的解决方案

  

我想知道每个令牌都仅对电话有效吗？例如，用户在应用程序中收到的令牌无法在邮递员或其他电话之类的软件中使用

我已经陶醉于通过实现* Mobile App Attestation **概念可以解决该问题，因此让我们看看它是如何工作的...

移动应用证明

移动应用证明解决方案的作用是确保在运行时您的移动应用未被篡改，不在有根设备中运行，没有被xPosed或Frida之类的框架检测，未被MitM攻击，这是通过在后台运行SDK来实现的。在云中运行的服务将对应用程序构成挑战，并基于响应将证明移动应用程序和设备正在运行的完整性，因此，SDK将不再负责任何决定。

Frida

  

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

xPosed

  

Xposed是用于模块的框架，可以在不触摸任何APK的情况下更改系统和应用程序的行为。太好了，因为这意味着模块可以用于不同版本甚至ROM，而无需进行任何更改（只要原始代码的更改不太多）。撤消操作也很容易。

MiTM Proxy

  

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

在成功证明移动应用程序完整性之后，将发布并使用一个秘密的短期生存JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务可以识别。如果移动应用程序证明失败，则会使用API​​服务器不知道的秘密对JWT令牌进行签名。

现在，应用程序必须随每个API一起发送，并在请求的标头中调用JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求，而在验证失败时拒绝它们。

一旦移动应用程序不知道移动应用程序证明服务使用的机密，即使在应用程序被篡改，在有根设备上运行或通过连接进行通信时，也无法在运行时对其进行反向工程成为中间攻击中一名男子的目标。

移动应用证明服务已经作为Approov的SAAS解决方案存在（我在这里工作），该服务为多个平台（包括iOS，Android，React Native等）提供SDK。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。对于API服务器来说，必须进行此检查才能决定要处理的请求和拒绝的请求。

摘要

因此，您了解到可以解决您的问题，但是最后，必须根据要保护的内容的价值以及相关法律要求来选择用于保护API服务器的解决方案。数据类型，例如欧洲的GDPR法规。

您想参加额外的战斗吗？

OWASP Mobile Security Project - Top 10 risks

  

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