安全审查：客户端信用卡# 存储在服务器上，但一次性加密存储在客户端 cookie 中

Posted 2023-02-22

【中文标题】安全审查：客户端信用卡# 存储在服务器上，但一次性加密存储在客户端 cookie 中

【英文标题】：Security review: client credit card# stored on server but with one time pad encryption stored in client cookie

【发布时间】：2010-10-17 01:04:17

【问题描述】：

我正在编写一个系统，与往常一样，客户要求提供方便的“记住您的信用卡详细信息”选项。

我已经告诉他们，这很可能是不可行的。但是，我刚才确实有一个好主意（tm），看到加密中的好主意（tm）实际上是坏主意（tm），我想我会把它放在这里进行审查，看看可以打出什么洞通过它。

基本上，我正在考虑xor'ing 信用卡信息以及使用每个客户生成的一次性便笺簿的一些消息签名。该垫作为 cookie 变量存储在客户端浏览器上。 下次用户尝试进行购买时，pad 会被发送到服务器，如果服务器可以正确解码其加密数据，它会显示信用卡信息已被填写。 （抄送信息实际上并未传回）。服务器永远不会将 pad 存储在内存或页面文件之外的任何内容中。事实上，我打算将 pad 发送两次：一次在到达 CC 页面时（服务器检查它是否应该请求 CC 信息），一次在 CC 提交时获取实际信息。

用户还将被告知他们的信息“部分存储”在他们的 cookie 缓存中，这意味着他们预计如果他们的 cookie 被刷新，他们的 CC 信息就会丢失。

让我知道你认为这个计划在哪里严重失败。

【参考方案1】：

听起来很粗略，我很确定你误用了“一次性便笺簿”这个词。

不要走这条路，而是考虑使用像 Authorize.net 的Customer Information Management 这样的服务。基本上，你给他们卡信息，他们会给你一个 ID，你可以用它来为卡充电。该 ID 与该网站的商家帐户相关联，不能用于向任何其他商家充值。

它要安全得多，而且应该得到相同的结果。

注意：我不支持 Auth.net 或其 CIM。这只是我最熟悉的例子。

【参考方案2】：

我认为，存储 pad 客户端会使其容易受到 XSS 攻击。

【讨论】：

你能解释一下，因为我真的没有看到一个场景。服务器将尝试解密完整的数据包，该数据包还将包含整个消息的签名。要么全有，要么全无。

如果您在 cookie 中存储任何敏感信息，攻击者可以通过 XSS 获取。您在 cookie 中存储了一些敏感信息。

【参考方案3】：

技术上：有缺陷。

法律上：可能有缺陷。与律师交谈。

只有在安全保密的情况下，一次性便笺簿才有效。将其存储在 cookie 中绝对不能算作安全或机密（它是从服务器发送和从服务器发送的，它被放到用户的机器上，它可能是公共终端或共享机器）。这是一个非常糟糕的主意。这是一个聪明的想法，但最终非常有缺陷。我建议您阅读 PCI 合规性文档并按照其他人的做法（一般而言）：

不要这样做。 使用可安全存储 CC 并处理账单的支付处理器（例如 PayPal）。 设置一个单独且高度安全的支付网关，这台机器只处理信用卡交易，然后它会访问一个存储信用卡数据的安全机器。 请记住，存储信用卡号码基本上会违反 PCI，并且可能会违反任何商家协议，甚至可能在您的管辖范围内是非法的（隐私法等），请咨询律师。 不要这样做。严重地。寻找可以为您处理此问题的付款处理方。

【讨论】：

我理解您的不情愿，但请解释一下技术漏洞是什么。存在哪些信息泄露漏洞？我能想到的最严重的攻击是我可以在别人的帐户上下订单。 （PS。没有为我们的市场处理此问题的支付处理器）

【参考方案4】：

如果信用卡被存储在客户端，那么您将使用密钥存储它，这意味着它很容易受到攻击。

如果您要存储信用卡服务器端，那么您不需要存储在客户端上的加密密钥。

如果您所描述的情况是这样一种情况，即用户不仅无法选择是否要存储他们的详细信息，而且还要让他们重新填充而无需以任何方式进行身份验证。如果我来到一家网吧并为我预先填写信用卡详细信息字段，我会非常高兴！

【讨论】：

“如果您在信用卡服务器端存储，那么您不需要存储在客户端上的加密密钥的密钥”是什么意思。关键是他将一半的卡详细信息存储在服务器上（加密），一半存储在客户端（密钥），因此只有将它们放在一起时才能知道实际的卡号详细信息。