问题标签 [pci-dss]

我正在开发 j2ee Web 应用程序，我们有以下要求：应该不可能安装带有任意类的应用程序补丁。现在，补丁是通过手动添加带有修复程序的 jar 甚至单个类到服务器类路径或应用程序 EAR 来完成的。我们也不能使用签名的 jar，因为不可能从它们覆盖以后的类。您能否针对这些要求提出解决方案？
说明：要求来自 PCI PA-DSS 标准。
当前的修补程序如下工作：例如，我们的 jar 之一是从系统类路径加载的。在标准的补丁过程中，额外的 jar 被添加到原始的之前的类路径中。因此，两个 jar 中存在的所有类都从新的 jar 中加载，因为因此会在 jar 中搜索类。根据要求应用程序必须验证所有加载的类都来自可信赖的来源，但目前至少理论上黑客有可能覆盖应用程序类并打开后门等。

可能的重复：

1. 使用 PHP 获取和存储信用卡信息的最佳实践
2. 存储信用卡详细信息
3. 存储信用卡信息

我需要在电子商务网站中存储信用卡号。我不打算存储整个信用卡号，因为这将是非常危险的。我想至少存储前五位数字，以便以后识别发卡的金融机构。理想情况下，我想尽可能多地存储信用号，以帮助将来进行交叉引用等。

我可以安全地存储多少位数字以及哪些特定数字？

例如，我想这不够安全：

因为你可以计算出丢失的数字。

同样，这将是安全的，但没有那么有用：

是否有一种公认的模式来存储部分信用号码？

Has anyone got practical experience or a reference for a scheme that implements a key management scheme that would comply with the PCI DSS security standard?

There are obviously quite a few implementations around given the number of companies compliant with PCI DSS but trying to find details of them is tough. When it gets down to storing private data the discussion normally stops at which encryption algorithm to use. After that there's normally a statement about appropriately storing the private key but no discussion about practical ways to do it or things like periodically changing the key or providing the key to applications etc.

Specificlly I'm interested in thee requirements from sections 3.5 and 3.6 of the PCI DSS standard.

3.5.2 Store cryptographic keys securely in the fewest possible locations and forms.

3.6.a Verify the existence of key-management procedures for keys used for encryption of cardholder data. Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

3.6.4 Verify that key-management procedures are implemented to require periodic key changes at least annually.

I've had a look at the NIST Cryptographic publications as the PCI DSS requirements document suggests but apart from recent notes of a Cryptographic Key Management Workshop there doesn't appear to be much there in the way of real implementable schemes or standards.

As to what I'm trying to do it's not:

1. Store passwords + salts as one way hashes for authentication,
2. Choose a strong symmteric algorithm for data encryption,
3. Avoid needing to store private data in the first place.
4. Avoid the need for key management with other mechanisms: physical security, database security, dragons and wizards etc.

All of which are valid concerns but in this case are not the answer. The nuts and bolts of my requirements are in a different SO question .Net Design pattern for storing and retrieving sensitive per user data but it all boils down to key management hence this more refined question.

我们在单个可执行文件中发布了我们软件包的更新补丁。使用颁发给我们的证书，使用 Authenticode 数字签名对该文件进行签名。该文件被下载到我们的客户操作的 Windows XP 或 Vista 系统中，他们在其中运行它以更新我们的软件。

我们的 PCI 合规审计员已要求我们防范以下情况：

1. 下载我们的可执行文件后，恶意人员会更改该文件。细心的人将能够检查文件的属性并确定签名不再有效。
2. 恶意人员将更改后的可执行文件放置在不知情的用户可以运行它的地方。
3. 一个毫无戒心的用户运行更改的文件，释放未指定的破坏。

审计员认为，如果签名无效，有一种方法（或应该是一种方法）来阻止文件运行。

你知道如何做到这一点吗？

我们的应用程序已通过认证，并且在经认证的 PABP 兼容应用程序列表中。我们通过了最新的 PABP 1.4 认证。现在，PA-DSS 是新来的。它是从 PABP 1.4 自动升级到 PA-DSS 还是必须重新审核？

所以我想修改一个 PHP / MySQL 应用程序，以便安全地存储信用卡而不是 cvv 和银行帐户信息。PCI DSS 需要 1024 RSA/DSA。少数用户将获得私钥，以解密帐户信息的批处理文件，每月提交给支付处理器。我不清楚是否有可能拥有一个允许使用普通 8 位密码登录的用户安全地修改自己的帐户信息的系统。似乎这是不可能的，并且加密应该是单向的（即每个用户-> 管理员；永远不允许用户再次解密他们自己的信息），即使通过 SSL 连接，帐户信息也永远不会暴露给用户。或者是否有一种适当且简单的方法可以做到这一点，我不知道它是否符合 PCI DSS？

我有一个这样的购物车流程：

• 第 1 页。选择产品
• 第 2 页。在单页结账时输入地址、送货、信用卡详细信息。
• 第 3 页。用户确认订单 - 但我们想要最后一次追加销售的机会，因此我们必须能够更改收取的金额。如果用户放弃此页面，则不应向他们收费或授权任何东西，但我们必须能够打电话给他们并说服他们订购，而无需再次询问他们的电话号码。

• 第 4 页。收据页面

• 重复计费是以后的要求，具有可变的金额和时间表。（用户必须能够返回并更改他们的日程安排，而无需再次输入 CC 号码）。

这是我不想做的事情：

• 将用户发送到第三方页面（因为我想要单页结帐并保留品牌）
• 最小化 PCI 合规性要求
• 如果用户未确认，则授权付款并取消付款。这是在多个层面上自找麻烦！

由于我需要一个确认页面，我认为我需要使用某种标记化系统，例如由Braintreepayments提供的。您基本上将信用卡号存储在他们的服务上，然后他们会给您一个代表该号码的令牌。然后，您可以随时对该卡收取任何金额的费用。这当然似乎是最灵活的解决方案。

我有点绕圈子试图弄清楚这是否是最好的解决方案：

• 我不知道 BrainTree 是否是唯一一家提供此类服务的公司，但我也不相信它真的有必要。
• 如果我在会话中临时存储 CC 直到用户确认它，我仍然可以使用几乎任何支付网关。因此，问题变成了“我是否将 CC 临时存储在内存中是否重要”以及到什么程度。

“最纯粹”最安全的方法似乎是重定向到braintree（或提供类似网关的其他人）。

编辑（分配赏金后）：

我得出的结论是，我绝对必须有一个系统，我们只需要满足PCI A 级。一直在更详细地研究 PCI，这些问卷是针对无卡商家（即电子商务）的相关问卷。

SAQ A : (当 CC 号码甚至没有触及我们的服务器时)。如果您在网上销售，您仍然需要填写这份问卷，但这很容易。

SAQ D：（即使我们不存储 CC 号码，也会触及我们的服务器）

看看这些问卷，就会发现需求之间存在巨大差异。PCI 要求经常被误认为是一个简单的列表，例如“维护防火墙”、“安全策略”、“限制物理访问”——但如果你真的阅读问卷 D，你会发现它有更多的问题和要求. 例如，您必须回答您的服务器是否受到摄像机的保护，以及您的服务器上的数据加密类型。

我真的很高兴知道那里有哪些实际产品或供应商可以帮助我做我想做的事情。如果真的只有 1 或 2 家公司让我这样做，那么我需要知道。

我与 Braintree 没有任何关系，只是我设法进入了他们的电子邮件营销列表。他们只是我找到的唯一一家这样做的公司。如果你经营另一家公司做同样的事情，那么一定要吹响你自己的号角。随着时间的推移，PCI 要求只会变得更加严格，任何读过我的问题的人都可能已经意识到这一点。

我们在我们的一个网站上进行了 PCI 扫描，由我们的一位客户传递给我们。有许多看起来像这样的漏洞报告：

网络服务：80/443 应用程序 URL： http ://www.oursite.com/signup.php 响应包含 SQL Server 错误。这表明测试插入的危险字符穿透了应用程序并到达了 SQL 查询本身（即应用程序易受 SQL 注入攻击）。

总结测试信息： header: header X-Forwarded-For=%2527

我不确定他们怎么说他们在这里注入了代码？

他们提供的另一个例子是一个不同的 URL，据说这个问题与漏洞利用相同：

总结测试信息： header: header X-Forwarded-For='

编辑
我查看了此标头，它似乎仅由代理或负载均衡器设置（我们无论如何都不使用）。无论哪种方式，我自己都对其进行了欺骗，并且我们最终没有任何漏洞，所以我不确定他们在强调什么。由于我们不使用此标头，因此我不确定假定的攻击点是什么？

我们有一个所谓的漏洞的另一个例子是：

网络服务：80/443 应用网址： http ://www.oursite.com/products/product-na-here/370 测试成功在响应中嵌入了一个脚本，页面加载后执行用户的浏览器。这意味着该应用程序容易受到跨站点脚本的攻击。

总结测试信息：

路径：路径/products/product-na-here/370 -> /products/product-na-here/370，参数：header >'">alert(957652)

同样，我不确定这里标记了什么？

谢谢。

我正在尝试为运行 Magento 的专用服务器（Red Hat Enterprise Linux）获得 PCI 合规性。当我第一次在服务器上安装 Magento 时，我意识到 RHEL 附带的 PHP 版本对于 Magento (5.1.6) 来说太旧了。所以，我找到了一个 PHP 版本 5.2.11 的单独 repo，它让一切运行良好，但现在我陷入了困境。我的 PCI 合规性测试表明，由于我的 PHP 版本 < 5.3.1，它存在安全问题。如果我尝试更新到 5.3.1，Magento 会中断。我不想编辑 Magento 核心来解决这些问题，所以我想我需要的是一个带有 PHP 5.2.11 的 repo，但我可以自信地说/证明已经向后移植以修补 PCI 的问题合规性扫描识别。

我意识到这非常令人费解，但是如果您有任何建议/提示，我很乐意听到。

谢谢。

当卡的详细信息由第三方（例如 Paypal）处理时，哪些形式的电子商务合规性（例如 PCI-DSS）适用？

我正在构建一个使用 Paypal Express 的定制购物车系统，因此卡的详细信息永远不会到达我的服务器。但是，我确实保留了客户详细信息，那么我必须或应该遵守哪些合规性（无论是在代码级别还是硬件级别）？