3

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

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

这个设计有点集体努力，我对它的整体效果表示怀疑。我的问题是，任何人都可以看到下面显示的实现有任何明显的安全问题吗？它是矫枉过正还是不足？

编辑：进一步的讨论导致了更新的实现，所以我用新版本替换了原始代码并编辑了描述以与此修订版交谈。

（下面的代码是一种伪代码；原文使用了一些特殊的遗留库和结构，使其难以阅读。希望这种风格足够容易理解。）

// 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”都有自己的秘密盐密钥。
  3. 这些 BASE64_8192BIT_SECRET_A 和 _B salt 密钥是存储在服务器上的 RSA 私钥的一部分。
  4. “captcha_hash”用秘密和“session_hash”加盐。
  5. 在使用客户端提供的数据的地方添加分隔符，以避免拼接攻击。
  6. “captcha_hash”和“session_hash”都存储在客户端cookie中。

编辑：回复：Kobi 感谢您的反馈！

（我会在评论中回复，但它似乎不接受在问题中有效的格式？）

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

根据 Kobi 的建议，哈希数据中现在包含过期时间范围，但共识是将其添加到 session_hash 中，因为会话超时很直观。

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

问题：

  1. 有没有明显的不足？
  2. 有没有细微的缺陷？
  3. 有没有更稳健的方法？
  4. 用另一个哈希盐腌制哈希有什么帮助吗？
  5. 是否有更简单且同样强大的方法？

新问题：

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

4

1 回答 1

4

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

为了校准，你说：

“session_hash”旨在防止在多台机器上使用相同的 cookie。

真的吗？
在isCaptchaValid你正在做的事情上String session_hash = substring(cookie, 64, 64);——也就是说：你依赖于 cookie 中的数据。你怎么知道它不是从另一台计算机复制的？- 您不会再次对客户端数据进行哈希处理以确认它（事实上，您那里有一个随机数，所以它可能是不可能的）。你怎么知道它是新的请求，没有被使用？

我意识到每次登录都会替换验证码，但是你怎么知道什么时候发出请求呢？您没有检查新isCaptchaValid的验证码 - 您的代码仍将验证请求，即使它与显示的验证码不匹配。
考虑以下场景（可以自动化）：

  1. 夏娃打开登录页面。
  2. 获取一个新的 cookie 和一个新的验证码。
  3. 将其替换为她的旧 cookie，以及她旧 cptcha 的散列数据。
  4. 提交旧的 cookie，并userInputValue使用旧的验证码。
  5. 使用此输入，isCaptchaValid验证请求 - captcha_hash、session_hash和都与第一个请求相同userInputValue。BASE64_8192BIT_SECRET

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

于 2009-10-26T06:40:48.533 回答