API 密钥 + HTTP 签名 - 为什么要同时使用两者?

API key + HTTP Signature - why use both?

提问人:sakura-bloom 提问时间:3/6/2023 更新时间:3/20/2023 访问量:572

问:

我正在尝试保护 API 并研究保护它的方法。我见过不同的 API 使用不同的方法:

  • API 密钥 + HTTP 签名
  • OAuth 客户端凭据流 + HTTP 签名

现在,我想知道HTTP签名本身还不足以证明身份吗?为什么要将它与其他东西(如 API 密钥或 OAuth)结合使用?

身份验证 安全 API 密钥

评论

0赞 Marek Puchalski 3/6/2023
这是一个很好的问题。我不知道确切的原因,但我可以试着猜测。我相信简单的 API 密钥身份验证或 OAuth 凭据验证速度很快,并且不会占用太多 CPU。验证 HTTP 签名可能需要一段时间和一点 CPU 能力,并且只有 HTTP 签名将为 DDOS 攻击打开大门。

答:

0赞 Exadra37 3/8/2023 #1

您的问题

现在,我想知道HTTP签名本身还不足以证明身份吗?

假设您使用 HMAC 对 HTTP 请求进行签名,那么它只能证明 HTTP 请求中消息的完整性和真实性,或者换句话说,它没有在传输过程中被修改,但前提是您知道发出请求的内容确实是您所期望的,是您的移动应用程序的真实且未经修改的版本, 不会受到任何形式的攻击,否则您可能会获得被攻击者欺骗的 HMAC 签名。

为什么要将它与其他东西(如 API 密钥或 OAuth)结合使用?

API 密钥将向 API 服务器提供应用程序的唯一标识符,而 OAuth 令牌将提供使用所述应用程序的用户的身份。

因此,在我继续回答您的问题之前,我想首先澄清一个关于什么在访问 API 服务器的误解。

WHO 和 WHAT 之间的区别是访问 API

在文章中,为什么您的移动应用程序需要 API 密钥? 您可以详细阅读访问您的 API 服务器的人和内容之间的区别,但我将在这里摘录其中的主要内容

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

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

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

当你掌握了这个想法,并在你的思维方式中根深蒂固时,你就会从另一个角度看待 API 安全,并能够看到你以前从未存在过的攻击面。

通过 MitM 攻击从 API 请求中提取机密

现在,我想知道HTTP签名本身还不足以证明身份吗?为什么要将它与其他东西(如 API 密钥或 OAuth)结合使用?

您可以而且应该使用所有这些方法,以增加攻击者使用看起来像是由 API 的真正客户端发出的请求来模拟您的 API 后端所需的难度。

问题在于,API 请求可以通过 MitM 攻击被拦截,即使使用 HTTPS,正如我在我的文章中展示的那样 窃取 Api 密钥与中间人攻击

为了帮助演示如何窃取 API 密钥,我在 Github 上构建并发布了适用于 Android 的 Currency Converter Demo 应用程序,该应用程序使用我们在早期的 Android Hide Secrets 应用程序中使用的相同 JNI/NDK 技术来隐藏 API 密钥

因此,在本文中,您将学习如何设置和运行 MitM 攻击来拦截您控制的移动设备中的 https 流量,以便您可以窃取 API 密钥。最后,您将在较高层次上了解如何缓解 MitM 攻击。

当攻击者执行 MitM 攻击时,他也有可能修改和重放请求,因此攻击者只需要反转客户端即可查看消息的签名方式,即可在 MitM 攻击中复制它,以篡改消息内容并重新签名,就好像它们是由客户端签名一样。您可以在实用 API 安全演练 — 第 3 部分一文中查看执行此操作的示例

这是迷你系列的第三部分,该系列使用虚构产品“ShipFast”,引导您完成防御移动应用程序中的各种漏洞的过程,以访问远程服务器上的数据,从而允许系统的真实用户以牺牲公司为代价获得不公平的商业优势。

本文将向您展示一个示例,该示例使用静态和动态 HMAC 保护 API 请求消息完整性,以及攻击者如何绕过它们。它包括代码示例,但您也可以克隆 Github 上的 Shipfast 存储库并使用它以更好地了解一切是如何工作的。

可能的解决方案

为什么要将它与其他东西(如 API 密钥或 OAuth)结合使用?

对于移动客户端

当 API 客户端是移动应用程序时,您可以查看我给出的以下答案:

  • 我建议您阅读我接受的问题的答案如何在没有人窃取令牌的情况下从我的移动应用程序中使用 API,其中运行时机密保护似乎是您的最佳选择。
  • 另一个选择是阅读我对如何保护移动应用程序的API REST问题给出的答案,特别是“强化和屏蔽移动应用程序”,“保护API服务器”和“可能更好的解决方案”部分。

对于 Web 客户端

对于 Web API,您可以学习一些有用的技术来帮助您的 API 后端尝试仅响应来自您期望的、您的正版 Web 应用程序请求,为此,我邀请您阅读我对问题的回答保护 API 数据免受应用程序外调用的影响,尤其是专门用于保护 API 服务器的部分。

你想走得更远吗?

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

对于 API

OWASP API 安全前 10 名

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

对于移动应用程序

OWASP移动安全项目 - 十大风险

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

OWASP - 移动安全测试指南

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

对于 Web 应用

网络安全测试指南

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

评论

0赞 sakura-bloom 3/10/2023
谢谢你的文章!在没有用户上下文的情况下,服务器到服务器的通信怎么样?那么HTTP签名就足够了,不是吗?
0赞 sakura-bloom 3/10/2023
“假设你提到使用HMAC对HTTP请求进行签名,那么它只能证明HTTP请求中消息的完整性,或者换句话说,它在传输过程中没有被修改。
0赞 Exadra37 3/20/2023
For server to server communications then you can use an API-key, add message signing and/or pinning for extra-security. If you want to go the extra-mile you can even do mutual TLS authentication between the two servers, but you need to control both.
0赞 Exadra37 3/20/2023
See the updated answer about HMAC