在 SESSION 中存储信用卡号 - 有什么办法吗？

Question

我非常了解 PCI 合规性，因此不需要在结帐过程中在我们公司的数据库中存储 CC 编号（尤其是 CVV 编号）。

但是，我希望在处理敏感的消费者信息时尽可能安全，并且很好奇如何在不使用 SESSION 变量的情况下在页面之间传递 CC 编号（如果可能的话）。

我的网站是这样构建的：

1. 步骤1）收集信用卡 来自客户的信息 - 何时 客户点击提交， 信息首先通过JS跑通 验证，然后通过 PHP 运行 验证，如果全部通过，他就会移动 到步骤 2。
2. 步骤 2) 信息显示在 供客户制作的评论页面 确定他们即将到来的细节 显示交易。只有 CC 的前 6 个和后 4 个是 此页面上显示但卡类型， 和到期日期均完整显示。如果他 单击继续，
3. 步骤 3) 信息发送至 另一个最后运行的 php 页面 验证，发送信息 通过安全支付网关，以及 返回带有详细信息的字符串。
4. 步骤 4) 如果一切顺利， 消费者信息（个人，非 CC）存储在DB中并重定向 到完成页面。如果有什么是 不好，他被告知并被告知 重新访问 CC 处理页面 再试一次（最多 3 次）。

有什么建议吗？

编辑

我在这个问题上收到了很多非常好的答复 - 大多数人似乎同意以下内容：

1. 在之后获取 POST 变量 验证正在运行，
2. 加密 ccnum 和 cvv（不确定 您可以将 cvv 存储在数据库中 无论如何）
3. 存储在临时数据库
4. 在“审查”后立即 访问数据库中 页面正常，
5. 从数据库解密详细信息，
6. 将信息发送到处理器，
7. 接收响应，
8. 终止数据库，

我认为这总体上是有意义的。有没有人有好的加密/解密方法以及创建临时数据库信息（在以后调用时自动删除）的最佳方法？

我正在使用 PHP 和 MySQL DB 进行编程

编辑#2

我遇到了 Packet General，这似乎是一个理想的解决方案，但真的不想支付另一个软件许可证来实现这个目标。 http://www.packetgeneral.com/pcigeneralformysql.html

编辑 # 3 - 示例代码

我现在发布了一些示例代码，我将它们放在一起，试图理解本文中提到的加密/解密/密钥和存储。希望已经有帮助的贡献者可以验证并且其他人能够使用类似的功能。出于篇幅考虑，我不会讨论用于实际 CC 编号本身的验证方法。

表单输入

<form action="<?php $_SERVER['PHP_SELF']; ?>" method="POST">
<input type="text" name="CC" />
<input type="text" name="CVV" />
<input type="text" name="CardType" />
<input type="text" name="NameOnCard" />
<input type="submit" name="submit" value="submit" />
</form>

PHP 加密和存储数据

<?php

$ivs = mcrypt_get_iv_size(MCRYPT_DES,MCRYPT_MODE_CBC);
$iv = mcrypt_create_iv($ivs,MCRYPT_RAND);
$key = "1234"; //not sure what best way to generate this is!
$_SESSION['key'] = $key;

$ccnum = $_POST['CC'];
$cvv = $_POST['CVV'];
$cctype = $_POST['CardType'];
$ccname = $_POST['NameOnCard'];

$enc_cc = mcrypt_encrypt(MCRYPT_DES, $key, $ccnum, MCRYPT_MODE_CBC, $iv);
$enc_cvv = mcrypt_encrypt(MCRYPT_DES, $key, $cvv, MCRYPT_MODE_CBC, $iv);
$enc_cctype = mcrypt_encrypt(MCRYPT_DES, $key, $cctype, MCRYPT_MODE_CBC, $iv);
$enc_ccname = mcrypt_encrypt(MCRYPT_DES, $key, $ccname, MCRYPT_MODE_CBC, $iv);


//if we want to change BIN info to HEXIDECIMAL
// bin2hex($enc_cc)

$conn = mysql_connect("localhost", "username", "password");
mysql_select_db("DBName",$conn);

$enc_cc = mysql_real_escape_string($enc_cc);
$enc_cvv = mysql_real_escape_string($enc_cvv);
$enc_cctype = mysql_real_escape_string($enc_cctype); 
$enc_ccname = mysql_real_escape_string($enc_ccname);

$sql = "INSERT INTO tablename VALUES ('$enc_cc', '$enc_cvv', '$enc_cctype', '$enc_ccname');

$result = mysql_query($sql, $conn) or die(mysql_error());
mysql_close($conn);

Header ("Location: review_page.php");

?>

PHP 解密数据并将其发送到网关，

    $conn = mysql_connect("localhost", "username", "password");
    mysql_select_db("DBName",$conn);

$result = mysql_query("SELECT * FROM tablename");

echo mcrypt_decrypt (MCRYPT_DES, $_SESSION['key'], $enc_ccnum, MCRYPT_MODE_CBC, $iv);
echo mcrypt_decrypt (MCRYPT_DES, $_SESSION['key'], $enc_cvv, MCRYPT_MODE_CBC, $iv);
echo mcrypt_decrypt (MCRYPT_DES, $_SESSION['key'], $enc_cctype, MCRYPT_MODE_CBC, $iv);
echo mcrypt_decrypt (MCRYPT_DES, $_SESSION['key'], $enc_ccname, MCRYPT_MODE_CBC, $iv);

mysql_close($con);
?>

然后继续获取刚刚在字符串中发送的数据并在网关提交中使用。看起来对吗？

Answer 1

这就是数据库的用途。我不确定这里的法律后果（根据国家和地区的不同而有所不同），但一种方法是加密 CC 号码，并在从用户那里收到它后立即将其存储在数据库中。您可能希望将最后 4 位数字存储在单独的字段中，以便在需要时向用户显示。当您需要与服务器上的卡处理器交互时，从数据库中检索并解密卡号。

Answer 2

这就是我计划如何做到这一点 - 当然，一切都使用 ssl 通过 https 进行。

步骤 1. 用户输入 CC 信息并按下一步按钮。 CC 信息立即保存到 CC 处理器的数据库中，而不是您自己的数据库中，否则您将违反 PCI 合规性。这一步实际上并不对 CC 收费。但您应该从处理器收到一些唯一的 ID，用于识别 CC 信息。 （如果需要，请将唯一 ID 存储在您的数据库中）

第 2 步。在确认页面上，使用 CC 处理器为您提供的唯一 ID 检索 CC 信息。无论如何，我的处理器只会让我检索 CC 的最后 4 个数字。

步骤 3. 确认购买并按下立即购买按钮后，使用唯一 ID 向信用卡收费。

步骤 4. 重定向到包含发票/收据的感谢页面，其中只有 CC 的最后 4 位数字（当然，您不必显示 CC 的最后 4 位，但我认为显示它是一件好事）。

Answer 3

您可以将卡号的哈希值存储在会话中，并将相同的哈希值和实际号码以及用户的会话 ID 存储在数据库中。然后，对于每个页面，您可以检查哈希值和会话信息以获取卡编号。

Answer 4

在支付处理稍后的某个时刻（第 3 步的最后一部分），您需要加密 CC#（和 CVC），以便能够将其发送到支付处理商（我认为）

为什么不正确进行加密当您收到信息时，旁边会出现确认页面所需的混淆。 （这是步骤 1 的最后一部分）

从现在开始，只处理这些加密或混淆的数据，使 CC 公司成为唯一能够真正解密完整数据的公司。

Answer 5

不需要会话或数据库来保存信息。

每个页面都是一个发布数据的表单。在每个后续页面上，上一页中的发布变量将添加到隐藏的表单字段中，以便下一个表单提交再次发布数据。这样就不会存储任何内容，但信息会逐页传送。这也迫使用户从头到尾完成该过程，而无需尝试跳过步骤。

只要通过 HTTPS 提交表单，数据就会自动加密，安全负担由您的 SSL 证书提供商承担。

许多流行的商业网站都实现了这一点。例如 OSCommerce。

Answer 6

使用标记化。其完全符合 PCI DSS 标准。

更多内容可以在这里找到，
https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf

Answer 7

将卡详细信息存储到任何持久性介质（数据库等），但使用存储在会话中的唯一和随机密钥对卡号进行加密。这样，如果会话丢失，密钥也会丢失 - 这使您有足够的时间来清除过期/废弃的数据。

还要确保您的会话免受劫持。对此有硬件解决方案，但一种简单的代码内方法是将会话 ID 与 IP 的第一个八位字节加上用户代理的哈希值联系起来。虽然不是万无一失，但有帮助。

编辑：
最大限度降低风险的关键是确保尽快摆脱该信息。交易完成后，立即从数据库中删除该记录。您还需要一个滚动作业（例如每 5 分钟一次）来删除任何早于会话超时（通常为 20 分钟）的记录。另外，如果您使用数据库来存储这些非常临时数据，请确保它不在自动备份系统上。

再次强调，这个解决方案并不是万无一失的，我什至不能 100% 确定它符合 CC 安全要求。但是，它应该要求攻击者对您的环境具有完全的运行时控制权，才能主动解密客户 CC 信息，并且如果您的数据库快照遭到破坏（更有可能/常见），则一次只能暴力破解一个 CC，这大概是你所能期望的最好结果了。

Answer 8

考虑修改您的结帐流程以消除存储信用卡信息的必要性。

第 1 页：用户输入非信用卡订单信息，例如送货地址和帐单地址
第2页：用户验证非信用卡订单信息，输入信用卡信息，然后单击“立即付款”（如果想要更改内容，则单击“修改订单”）
步骤 3：信息通过 $_POST 请求提交到 SSL 页面，该页面完成服务器端检查，将信用卡数据提交给处理器，并根据响应将用户引导至成功或错误页面。

这样您就可以避免技术问题和合规性问题的困扰。将信用卡数据存储在数据库或 cookie 中，即使时间很短，即使已加密，也意味着您要对更高级别的 PCI 合规性负责。唯一的缺点是您将无法显示包含信用卡详细信息的“查看订单”页面。鉴于您的“查看订单”页面甚至无法显示完整的信用卡号码，这有多大的权衡呢？

Answer 9

我知道您提到过您了解 PCI 合规性，但使用任何已经描述的方法（例如将卡号保存到光盘上的任何地方）都会违反 PCI，并且意味着您将面临合规性头痛的噩梦。如果您确实坚持将卡号保存到光盘上，那么您不妨现在就聘请 PCI 审核员来帮助您完成整个过程并提供建议。最终他们需要验证您所采取的方法是否合适。

例如，这里的很多答案都谈到使用加密。这就是最简单的一点。他们还没有谈论密钥管理，这是重要 更难

因此，我认为更好的方法是在收集卡详细信息后立即将其提交到支付网关。许多支付网关将允许您执行“仅存储”式交易，该交易将执行卡详细信息的基本验证并将卡号存储到其（已符合 PCI 标准）服务器，并返回您一个令牌 ID。这种方法意味着您不必将完整的卡号/cvv2 存储在服务器上的任何位置，并且 PCI 合规性变得更加容易。

稍后在结账过程中，您可以使用令牌 ID 提交授权和结算。

PCI 允许您以明文形式存储卡号的前六位/后四位数字（和到期日期），因此您可以在您愿意的任何地方安全地捕获这些数字，以便可以在最后一步之前重新显示它们。

Answer 10

您是否有任何原因无法跳过确认步骤并立即提交交易？

我不明白为什么将其保存在数据库中比将其保存在会话变量中更安全 - 服务器妥协仍然会泄露信用卡号，但如果将其保存在会话中，则它被写入的可能性要小得多磁盘。如果需要，您可以对其进行加密，但其用途值得怀疑（它仍然会被交换到磁盘）。添加另一台机器来进行加密存储也没有帮助，因为受感染的机器只能要求另一台机器进行解密。

编辑：只是想到了这一点：

1. 生成一个随机的 128 位密钥。将其保存在会话中。
2. 使用密钥加密数据。在 中将其发送到客户端
3. 确认后，解密数据并提交交易。

攻击者需要破坏客户端和服务器才能获取信用卡号（无论如何，这样的攻击者可能已经拥有该号码）。在线服务器的入侵仍然会获得未来交易的信用卡号码，但你无法真正阻止它。

编辑：我忘记了细节。对于所有这些方案（不仅仅是我的），您还需要一个 MAC 来防止重放攻击（或者 Eve 分散 Alice 的注意力，修改购物篮和账单地址，然后点击“确认”页面...）。一般来说，您希望拥有所有交易数据（CC、CVV、交易 ID、交易金额、账单地址...）的 MAC。

Answer 11

你是对的，使用会话来存储敏感数据是非常不安全的，有一些方法可以通过以下方式闯入会话：

会话劫持
会话固定

我想到的最安全的方法是将信息存储在数据库中（临时），然后在需要的页面上读取该值。完成所有操作后，您可以将其删除。

请注意：

• 在保存到数据库之前，您必须对其进行加密。
• 如果您使用的是共享主机，请务必小心
• ，请确保在使用完毕后将其删除，

您可能会发现这反思也很有用:)

Answer 12

看来无论您如何触摸它，您都需要提供安全的信用卡号存储功能。如果服务器受到威胁，它随时都会包含足够的信息来解密当前存储的信用卡号码（即密钥和加密号码）。潜在的解决方案是使用充当“加密器/解密器”服务的内部服务器，仅此而已。通过这种方式，入侵一台机器不会暴露信用卡号码。

Answer 13

还有另一种方式，但是需要Ajax。不存储信用卡号码和评论页面。

第 1 页：用于获取运输、账单和信用卡信息的表格。确保页面的“主体”（包括表单）位于具有唯一 ID 的 DIV 中，以便您可以使用 JavaScript 引用它。

第 2 页：服务器上的一个文件，它将接受带有表单字段的 GET/POST 请求，并根据您的喜好返回格式正确的“评论”页面。

结账流程：

1. 验证表格。
2. 将信用卡相关字段复制到全局 JavaScript 变量中。
3. 循环遍历表单字段并使用表单字段（不包括信用卡相关字段）构建查询/数据字符串
4. 对“评论”页面执行 Ajax 请求，并传递表单字段/值的查询字符串。在服务器上渲染并返回调用 Ajax 函数。
5. 获取从 Ajax 请求返回的渲染 HTML 审核页面，并用它替换“DIV”容器中的内容（有效地用审核 HTML 替换表单和其他元素）。
6. 使用 JavaScript 将全局 JS 变量中存储的信用卡数据复制到评论页面的适当位置。您还可以将卡片数据复制到隐藏表单字段，以便在用户从“审核”页面“完成”订单时提交。
7. 用户从审核页面向服务器提交订单，使用处理器的网关执行卡验证，然后下订单或返回错误处理页面，而无需存储卡详细信息。
8. 我建议“下订单”函数执行完整的 HTTP 请求（而不是 Ajax），以便使用不再将卡片数据存储在全局 JS 变量中的页面重新加载浏览器。

这有点像黑客，但如果做得正确，它对用户来说是 100% 无缝的，并且允许您一次性传输卡数据，而无需承担临时数据库存储等方面的风险。