gpt4 book ai didi

security - Captcha 哈希 cookie 的加密安全性

转载 作者:行者123 更新时间:2023-12-02 00:43:48 24 4
gpt4 key购买 nike

我公司的 CRM 系统在每次登录时都使用验证码系统,以便使用某些管理功能。原始实现将当前验证码值存储在服务器端 session 变量中。

我们现在需要重新开发它以将所有必要的验证码验证信息存储在散列的客户端 cookie 中。这是由于父 IT 策略旨在通过禁止尚未对应用程序进行身份验证的用户使用 session 来减少开销。因此,不允许身份验证过程本身使用服务器端存储或 session 。

该设计有点像团队合作,我对其整体效果表示怀疑。我的问题是,任何人都可以看到下面显示的实现有任何明显的安全问题吗,它是否在任何方面都过大或不足?

编辑:进一步的讨论导致了更新的实现,所以我用新版本替换了原始代码并编辑了描述以讨论这个修订。

(下面的代码是一种伪代码;原始代码使用了一些特殊的遗留库和结构,难以阅读。希望这种风格足够容易理解。)

// Generate a "session" cookie unique to a particular machine and timeframe
String generateSessionHash(timestamp) {
return sha256( ""
+ (int)(timestamp / CAPTCHA_VALIDITY_SECONDS)
+ "|" + request.getRemoteAddr()
+ "|" + request.getUserAgent()
+ "|" + BASE64_8192BIT_SECRET_A
);
}

// Generate a hash of the captcha, salted with secret key and session id
String generateCaptchaHash(captchaValue, session_hash) {
return sha256( ""
+ captchaValue
+ "|" + BASE64_8192BIT_SECRET_B
+ "|" + session_hash
);
}

// Set cookie with hash matching the provided captcha image
void setCaptchaCookie(CaptchaGenerator captcha) {
String session_hash = generateSessionHash(time());
String captcha_hash = generateCaptchaHash(captcha.getValue(), session_hash);
response.setCookie(CAPTCHA_COOKIE, captcha_hash + session_hash);
}

// Return true if user's input matches the cookie captcha hash
boolean isCaptchaValid(userInputValue) {
String cookie = request.getCookie(CAPTCHA_COOKIE);
String cookie_captcha_hash = substring(cookie, 0, 64);
String cookie_session_hash = substring(cookie, 64, 64);
String session_hash = generateSessionHash(time());
if (!session_hash.equals(cookie_session_hash)) {
session_hash = generateSessionHash(time() - CAPTCHA_VALIDITY_SECONDS);
}
String captcha_hash = generateCaptchaHash(userInputValue, session_hash);
return captcha_hash.equals(cookie_captcha_hash);
}

概念:

  1. “session_hash”旨在防止同一 cookie 在多台机器上使用,并强制执行一个时间段,之后它会失效。
  2. “session_hash”和“captcha_hash”都有自己的 secret 盐 key 。
  3. 这些 BASE64_8192BIT_SECRET_A 和 _B 盐 key 是存储在服务器上的 RSA 私钥的一部分。
  4. “captcha_hash”同时包含 secret 和“session_hash”。
  5. 在使用客户端提供的数据的地方添加分隔符,以避免拼接攻击。
  6. “captcha_hash”和“session_hash”都存储在客户端 cookie 中。

编辑:re:Kobi 感谢您的反馈!

(我会在评论中回复,但它似乎不接受在问题中有效的格式?)

每次他们访问登录页面时,验证码都会被替换;然而,这确实假设他们不会在不重新加载登录表单页面的情况下简单地重新提交。基于 session 的实现使用过期时间来避免这个问题。我们也可以向登录页面添加随机数,但我们也需要服务器端 session 存储。

根据 Kobi 的建议,过期时间范围现在包含在散列数据中,但共识是将其添加到 session_hash 中,因为 session 有超时是很直观的。

这种散列一些数据并在该数据中包含另一个散列的想法对我来说似乎很可疑。真的有任何好处吗,或者我们最好使用包含所有相关数据(时间、IP、用户代理、验证码值和 key )的单个哈希。在这个实现中,我们基本上是告诉用户散列明文的一部分。

问题:

  1. 有没有明显的缺陷?
  2. 是否存在任何细微的缺陷?
  3. 是否有更稳健的方法?
  4. 用另一种哈希对哈希进行加盐是否有帮助?
  5. 是否有更简单且同样可靠的方法?

新问题:

我个人认为我们最好将其保留为服务器端 session ;任何人都可以向我指出任何证明或反驳仅将所有验证数据发送到客户端的固有风险的论文或文章吗?

最佳答案

假设除了此处所述没有其他安全措施:
似乎攻击者可以一次解决验证码,并保存 cookie。
然后她有她的常量 session_hashcaptcha_hash。没有什么可以阻止她提交具有相同散列数据的相同 cookie - 可能会破坏您的系统。
这可以通过使用 time 作为 captcha_hash 的一部分来避免(您需要将它四舍五入到偶数时间,可能是几分钟 - 并检查两个选项 -当前时间和之前)

为了校准,你说:

The "session_hash" is intended to prevent the same cookie from being used on multiple machines.

这是真的吗?
isCaptchaValid 上,您正在执行 String session_hash = substring(cookie, 64, 64); - 也就是说:您依赖于 cookie 中的数据。你怎么知道它不是从另一台计算机复制的? - 你没有再次散列客户端数据来确认它(事实上,你在那里有一个随机数,所以这可能是不可能的)。你怎么知道这是新请求,还没有被使用过?

我知道每次登录都会替换验证码,但您怎么知道何时发出请求? 您没有在 isCaptchaValid 上检查新验证码 - 您的代码仍会验证请求,即使它与显示的验证码不匹配 .
考虑以下场景(可以自动化):

  1. Eve 打开登录页面。
  2. 获取一个新的 cookie 和一个新的验证码。
  3. 用她的旧 cookie 和她的旧 cptcha 的散列数据替换它。
  4. 提交旧 cookie 和带有旧验证码的 userInputValue
  5. 使用此输入,isCaptchaValid 验证请求 - captcha_hashsession_hashuserInputValueBASE64_8192BIT_SECRET 都与第一次请求时相同。

顺便说一句,在大多数系统中,无论如何你都需要一个随机数来避免 XSS,并且拥有一个随机数也可以解决你的问题。

关于security - Captcha 哈希 cookie 的加密安全性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1623343/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com