您如何强制合作伙伴对访问令牌进行安全存储？

Question

在开放API世界中，令牌是门钥匙（颁发给具有有效客户端ID和密码的任何人）。令牌允许拥有令牌的任何人访问资源。因此，它们与密码一样重要。

示例：希望访问您的API的第三方Native App。该应用程序使用“客户端ID和机密”来请求“访问令牌”。此访问令牌将用于后续的API调用。

关注：通常，“访问令牌”的TTL较长。将它们存储在Mobile App / Client移动设备中后，如果有人获得了访问权限，他们将能够使用此访问令牌和API URI重播来自其他来源的API调用。

1. 如何防止此类重播攻击（当访问令牌为 从第三方应用程序入侵而来）进行API调用？
2. 您遵循什么安全惯例来允许您的消费者/客户 安全地存储“访问令牌”？

Answer 1

在开放API世界中，令牌是门钥匙（颁发给具有有效客户端ID和密钥的任何人）。

我喜欢这个比喻：）

代币重要性

令牌允许拥有令牌的任何人访问资源。因此，它们与密码一样重要。

更关键的是，由于它们控制对API的访问，因此，使用被盗令牌进行的自动攻击可以在几秒钟，几分钟或几小时内根据该API的大小在该API后面窃取所有数据。 ，以及是否实施了限速或其他类型的防御措施，而数据泄露和 GDPR 下的罚款可能会是巨大的，甚至可能使公司倒闭或陷入严重困境。

具有刷新令牌的访问令牌

示例：想要访问您的API的第三方第三方应用程序。该应用程序使用“客户端ID和机密”来请求“访问令牌”。此访问令牌将用于后续的API调用。

注意事项：通常，“访问令牌”的TTL较长。将它们存储在Mobile App / Client移动设备中后，如果有人获得了访问权限，他们将能够使用此访问令牌和API URI重播来自其他来源的API调用。

访问令牌至少应该是短命的，并且客户端，移动应用程序或Web应用程序绝不应是请求颁发该令牌的人，而其各自的后端应该是向OAUTH请求该令牌的后端提供程序，并使用刷新令牌机制来保持发行短时令牌（应在几分钟内）。这种方法限制了被破坏的令牌可以被恶意请求重用的时间。

因此，我建议您切换到使用刷新令牌，这将使访问令牌的寿命很短，而刷新令牌的寿命却很长，但是要在小时范围内，而不是几天，几周或几年。

刷新令牌流的示例：

来源： Mobile API Security Techniques - part 2

注意：：尽管以上图形属于在移动API上下文中撰写的一系列文章，但它们具有很多信息，这些信息对于服务于Web应用程序和第三方客户端的API也有效。

通过使用刷新令牌方法，当客户端请求由于短期访问令牌过期而失败时，则客户端需要请求新的短期访问令牌。

这里重要的一点是，刷新令牌不应发送到浏览器或移动应用程序，只能发送短期访问令牌，因此您的第三方客户端必须将刷新令牌设为私有，也就是后端他们绝不能从javascript或他们的移动应用发送刷新令牌，而必须将任何短期访问令牌的更新委托给他们的后端。

这是一个很好的改进，但是只能确定谁正在发出请求，而不是什么正在发出请求，因此您的API继续运行而无法完全信任他们从受信任来源收到的请求。

哦，等等... 谁和什么让我感到困惑。好吧，您不是唯一的一个，这确实是开发人员中常见的误解。

谁和什么之间的区别在于访问API服务器。

这在我写的this article中有更详细的讨论，我们可以在其中阅读：

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

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

如果引用的文本不足以使您理解差异，请继续阅读本文的整个部分，因为如果没有充分理解，您很可能在API服务器中采用不太有效的安全措施，并且客户。

API重播攻击

如何防止API调用遭受此类重播攻击（当访问令牌从第三方应用程序泄露时）？

这是一个非常需要解决的问题，因为您的API需要知道什么正在发出请求，而且现在看来只能知道代表该请求发出了一些谁。

有关缓解API重播攻击的更深入方法，请阅读我在另一个问题中提出的this answer的缓解重播攻击部分：

因此，您可以让客户端使用请求网址，用户身份验证令牌，您的临时令牌以及应该在请求标头中显示的时间戳来创建HMAC令牌。然后，服务器将从请求中获取相同的数据并执行其自己的HMAC令牌计算，并且仅在其自身的结果与请求中的HMAC令牌标头匹配的情况下才继续处理请求。

有关实际操作的实际示例，您可以阅读this blog series的第1部分和第2部分，其中涉及在移动应用程序上下文中的API保护技术，该功能还具有模拟移动应用程序的Web应用程序。

它提供了一些用于HMAC实现的代码示例，因此，我真的建议您研究一下，但是请记住，HMAC只会使破解更加困难，并非不可能。

因此，当访问令牌属于Web应用时，这是一个很难解决的问题，但是对于使用移动应用证明解决方案的移动应用而言，这是可行的，这在this section中进行了描述我写的另一篇文章中，我将引用以下文本：

为了知道是什么向API服务器发送了请求，移动应用程序证明服务在运行时将高度确定您的移动应用程序存在，未被篡改/重新打包，未运行在具有根权限的设备中，尚未被检测框架（Frida，xPosed，Cydia等）钩住，并且不是Man in the Middle Attack (MitM)的对象。这是通过在后台运行SDK来实现的，该SDK将与在云中运行的服务进行通信，以证明移动应用程序及其所运行的设备的完整性。

为在移动应用程序使用API​​时保护您的API，建议您阅读我给this answer提供的保护API服务器和一种可能的更好解决方案部分如何保护移动应用程序的API REST？ （如果嗅探请求为您提供了“钥匙”）。对于Web应用程序，建议您阅读my answer中的 Web应用程序部分，以了解问题如何保护REST-API？。

>

存储访问令牌

您遵循什么安全惯例来允许您的消费者/客户安全地存储“访问令牌”？

在Web应用程序中，提取任何令牌所需的全部操作就是点击F12并寻找它们，但是在移动应用程序中，您需要对它们进行反向工程。

对于移动应用，您可以通过查看存储库android-hide-secrets来了解其隐藏方式，其中最有效的方法是利用{{3} }由Android提供的界面。您可以在仓库JNI/NDK和currency-converter-demo的应用程序中看到使用此方法的更多实际使用的演示应用程序。例如，请参见shipfast-api-protection-demo，如何使用here方法从C code加载配置。但是请记住，尽管这很难对移动应用程序二进制文件进行静态反向工程以提取秘密，但它并不能为攻击者提供任何安全保障，并且无法使用和检测框架来挂钩返回从密钥返回秘密的代码。 C代码，或执行MitM攻击以拦截移动应用程序与后端之间的请求，从而掌握您保护得很好的秘密。

移动应用程序可以使用移动应用程序证明解决方案来解决此问题，因为它们的代码中根本没有任何秘密，因此，如果您已阅读我之前提供的JNI/NDK，供移动应用程序使用以保护您的API ，那么您将更加熟悉移动应用证明的工作原理，并能够更好地理解为什么您可能希望让您的客户使用您的API，如下所示：

因此您的API将与 API 部分中已有的API并排放置，并且访问它的秘诀不再位于公共领域，而是安全地存储在反向代理保管库中。请注意，绿键是在运行时由云中的Mobile App Attestation服务提供的，并且移动应用程序不知道JWT令牌是有效还是无效。如果您还没有这样做，请阅读我已经提供给另一个答案的link，以便您更详细地了解证明的工作原理。

总而言之，这种方法不仅使您的API受益，因为它还提高了客户端移动应用程序的整体安全性。

走得更远

像往常一样，如果不推荐OWASP基金会的出色工作，我将无法完成与安全性相关的回答：

link：

OWASP Web安全测试指南包括用户可以在自己的组织中实施的“最佳实践”渗透测试框架，以及描述了用于测试最常见的Web应用程序和Web服务安全问题的技术的“低水平”渗透测试指南。

The Web Security Testing Guide：

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