客户端保护令牌漏洞循环困境

Client side securing token vulnerability circular dilemma

提问人:sabri mahmoud 提问时间:10/26/2023 更新时间:10/26/2023 访问量:33

问:

很抱歉,这个问题需要很长,以便您可以理解问题,并且它绝对是相对于我的问题的大小而言的,我正在寻求网络安全专家的意见,因此感谢您提前抽出时间。

I) 背景

在Google Analytics的相同上下文中,我的问题,主要目标是从前端收集数据,但我无法访问前端,并且通过添加我的客户端(如Google Analytics)远程服务器加载到前端的JavaScript脚本。此脚本将数据发布到 API,但请记住,前端没有身份验证过程(例如,将前端想象成一个教程网页)。我的目标是保护这些帖子请求,但我遇到了一个挑战。

问题在于,通常用于身份验证和安全性的 HTTP cookie(仅限 HTTP 文档)需要初始身份验证过程来设置令牌的 cookie。这意味着,在进行任何身份验证之前,我想要保护的数据和令牌可能仍可在客户端显示。这是一个重大漏洞,因为它意味着任何有权访问前端的人(包括潜在的攻击者)都可以看到并可能利用此数据。

由于我无法控制前端,因此在客户端实施安全措施(如身份验证或授权)更具挑战性。

enter image description here

II) 已采取的措施

a) 基于令牌的身份验证和源 URL 过滤

鉴于这些资源限制,我为我的 Web 客户端实现了一个短期的基于令牌的身份验证系统。此方法将客户端交互限制为特定的 API 端点,从而实现对客户端请求的控制和监视。此外,我还使用源 URL 过滤来根据传入请求的来源来验证传入请求。

b) 身份访问管理系统

在追求强大的安全解决方案的过程中,我探索了身份和访问管理系统作为潜在的途径。在我考虑过的选项中,Keycloak已成为一个有前途的解决方案。然而,在这种情况下,我遇到了一个反复出现的挑战。

与其他IAM系统一样,Keycloak要求在应用程序中包含敏感数据。例如,Keycloak的初始化需要提供配置详细信息,如下图所示:

import Keycloak from 'keycloak-js';

const keycloak = new Keycloak({
   url: 'http://keycloak-server${kc_base_path}',
   realm: 'myrealm',
   clientId: 'myapp'
});

try {
   const authenticated = await keycloak.init();
   console.log(`User is ${authenticated ? 'authenticated' : 'not authenticated'}`);
} catch (error) {
   console.error('Failed to initialize adapter:', error);
}

您可以在文档中找到所需的所有信息

这种情况给我带来了一个反复出现的难题,因为我发现自己处于一个有点循环的困境中。虽然像Keycloak这样的IAM系统提供了安全增强功能,但它们也需要在应用程序代码中包含敏感数据,这反过来又会带来安全问题。

III) 遇到的问题和局限性

a) 缺乏增强 DDoS 安全性的资源

在缓解 DDoS 攻击方面,我遇到了资源限制,例如缺乏基于云的基础设施,这限制了我实施某些安全措施的能力。具体而言,由于资源限制,多次克隆 API 作为分配流量和减少 DDoS 攻击影响的手段的选项目前不可行。

b) 源域名过滤漏洞

然而,重要的是要承认这种方法并非没有漏洞。主要问题是它依赖于源域名作为过滤请求的手段。虽然这种方法在正常情况下可能有效,但它仍然容易受到特定类型的威胁。

c) 漏洞场景

该漏洞在于,攻击者意图破坏系统,可能会创建一个伪造服务器,该服务器通过使用相同的域名来模仿我的客户端前端。这样一来,他们就可以制作和发送模仿合法客户交互的请求。缺乏可靠的身份验证过程,再加上对源 URL 过滤的依赖,为利用创造了机会。

我欢迎与对这一主题感兴趣的个人进行进一步讨论。我们可以一起探索与我面临的具体挑战相一致的潜在解决方案。

感谢您抽出宝贵时间接受采访

安全性 访问令牌 客户端攻击 API 安全性

评论


答:

0赞 HTTP 410 10/26/2023 #1

威胁模型

如果我没看错的话,您的大部分威胁模型都涉及滥用应用程序前端和 API 之间的信任。这些威胁的一些示例包括欺骗攻击、中间人攻击和重放攻击。

潜在的解决方案

如果我的解释是正确的,那么我建议你考虑将双向 TLS (mTLS) 作为威胁模型的潜在解决方案。

它是如何工作的

通常,在 TLS 中,服务器具有 TLS 证书和公钥/私钥对,而客户端则没有。因此,典型的 TLS 过程是这样的:

  1. 客户端连接到服务器
  2. 服务器提供其 TLS 证书
  3. 客户端验证服务器的证书
  4. 客户端和服务器通过加密的 TLS 连接交换信息

Normal TLS

但 TLS 还提供使用客户端 X.509 身份验证的客户端到服务器身份验证。客户端(在本例中为应用的前端服务器)和服务器(在本例中为 API 服务器)都有一个证书,并且双方都使用其公钥/私钥对进行身份验证。与常规 TLS 相比,mTLS 中还有其他步骤来验证双方(其他步骤以粗体显示):

  1. 客户端连接到服务器
  2. 服务器提供其 TLS 证书
  3. 客户端验证服务器的证书
  4. 客户端提供其 TLS 证书
  5. 服务器验证客户端的证书
  6. 服务器授予访问权限
  7. 客户端和服务器通过加密的 TLS 连接交换信息

Mutual TLS

它如何防止威胁

相互身份验证可以防止欺骗攻击,因为服务器也会对客户端进行身份验证,并在允许任何进一步的通信和访问之前验证它是否具有正确的会话密钥。

相互身份验证可以防止 MITM 攻击,因为发送方和接收方在发送消息密钥之前会相互验证。因此,如果其中一方未被验证为他们声称的身份,则会话将结束。

相互身份验证可以防止重放攻击,因为时间戳是协议中使用的验证因素。如果时间更改大于允许的最大时间延迟,则会话将中止。此外,消息可以包含随机生成的号码,以跟踪消息的发送时间。