发布到托管服务时安全支付中的潜在漏洞答案

【问题标题】：Potential vulnerability in Secure Payments when POSTing to a hosted service发布到托管服务时安全支付中的潜在漏洞
【发布时间】：2012-08-13 05:23:19
【问题描述】：

我正在实施一个简单的商店来接受付款。我正在使用托管商店解决方案。它的工作方式是：

我的页面负责构建购物车。到了收钱的时候，我的页面会重定向到托管商店。
托管商店将处理交易。
托管商店会将结果重定向回给我。

我想确保交易尽可能顺利和安全地进行。商店的文档使该过程看起来非常简单。下面是真正需要发送给商店提供商的所有内容，从他们的文档中获取。

<FORM METHOD="POST" ACTION="https://www.fakehostedstore.com/xxx/index.php">
    <INPUT TYPE="HIDDEN" NAME="store_id" VALUE="abcdefg">
    <INPUT TYPE="HIDDEN" NAME="store_key" VALUE="hijklmnop">
    <INPUT TYPE="HIDDEN" NAME="charge_total" VALUE="100.00">

    <!--MORE OPTIONAL VARIABLES CAN BE DEFINED HERE -->

    <INPUT TYPE="SUBMIT" NAME="SUBMIT" VALUE="Click to proceed to Secure Page">
</FORM>

这让我有些担心。例如，如果我打开Firebug 之类的东西，我可以在提交表单之前将“charge_total”更改为我喜欢的任何内容。很快，我可以将要发送到商店的费用金额从“100.00”减少到“10.00”。将进行收费的商店不会更聪明，会继续进行错误的收费。

如果交易在商店完成，商店会退回成功收取的金额。然后我可以验证我的预期费用。例如，我预计收取 100 美元的费用，但只收取了 10 美元，WTF！

有没有办法保护这种形式，使其不易被篡改？

【问题讨论】：

标签： post security payment-gateway payment-processing

【解决方案1】：

我认为您对此无能为力，除非他们改变处理付款的方式（例如，您在他们的服务中以固定价格注册产品，然后他们返回产品 ID、用户输入她想购买的物品数量，然后他们计算他们这边的总价格）。

他们是否会从服务中向您发回一些数据（例如已提取的金额）？除了等待钱出现在银行账户之外，您是否有可能看到用户支付的金额（响应值、一些 API 调用等）？否则，他们的设计存在严重缺陷。

关于篡改，您实际上无法阻止高级用户更改值。它甚至不必在浏览器级别完成——她可以使用像 Fiddler 这样的代理来篡改 HTTP 请求。

但是，您是否应该担心它，取决于您销售的产品和方式。如果它是一些即时销售平台（例如您可以访问某些互联网资源等），那就不好了。如果商店是一家通过邮寄方式发送东西的五金店，您每次都可以验证收到的金额，并将其与预期的金额进行比较（我想，会有一些自动工具来查找银行账户上的收款，因为通常，在您看到钱在您的帐户上之前，您不会向用户发送东西）。

我立刻想起了自己某天在某处读过的类似内容（很可能是在 SO 上）：在早期的互联网商店中，您有时可以输入类似 0.01 的内容在“数量”字段中，在服务器上，价格是通过乘法计算的（所以您支付了 0.01 实际价格！），而数量被四舍五入为整数！

编辑：他们是否有关于他们给出的回复的文档？您是否尝试过进行虚假交易？

编辑 2：由于商店会退还您收取的费用，这很好。但是，这仍然可能给商店带来问题（非技术性），因为这笔钱仍然将被收取。您可以在下一个屏幕上显示信息，说您收到的金额比您想要的少 10 倍，但您仍然必须将这笔钱退还给作弊者（否则将是非法的）。

很遗憾本店没有提供某种消息验证码的处理。事实上，有一个很好的方法可以防止这种作弊。但是，两个服务器必须在这方面合作。

看看HMAC。它看起来很复杂，但想法很简单。我将在简化算法上进行解释。

你有一个输入，比如price=100。你把它交给第三方。这个时候，很容易被篡改。但是假设我们发送了额外的字段，price_verification。我们可以使用预先约定的哈希函数和预先约定的盐来计算这一点（您和支付服务器都必须知道它）。然后你计算，比如price_verification=SHA1(price + someLengthySalt) 并将其发送到支付服务器。他们知道算法和盐，所以他们计算SHA1(received_price + someLengthySalt)。如果两者不同，则用户是骗子，您中止交易。当然，只要用户不知道算法和/或盐，这是安全的，所以他不能轻易计算price_verification。

但是盐应该非常强，并且算法可能更复杂，例如SHA1(SHA1(price)+salt) 等）。需要考虑的是价格的输入空间非常小（只有小数点后 2 位的数字 - 如果没有盐很容易被暴力破解）。

这可以很容易地扩展到验证任意数量的参数（您只需要就如何序列化数据达成协议）。

【讨论】：

该提供商确实提供了假商店和运行假交易的能力，所以我确实计划利用这一点。商店通过 POST 返回交易是否成功、收取的金额以及其他一些详细信息。我确实打算将商店收取的金额与我预期的收费金额相匹配，所以我会知道收费是否被更改。
很遗憾，您无法管理商店本身的产品列表。我同意这将是一个不错的选择！
查看我的第二次编辑。也许他们确实提供了一些 MAC 但你忽略了它？
文档没有提到任何类型的散列，但是如果它可用，那就太好了。也许这是为了简单起见而隐藏的功能，但如果您提出正确的问题，您可以启用它。我只能希望。

【解决方案2】：

我想我会提到商店建议如何处理这个潜在的安全问题。也许这适用于其他正在实施安全托管商店页面的人。

商店提供两种付款方式。第一个，“购买”，立即从信用卡中取款。这是我使用的方法。这很容易实施，但不能保证从卡中收取适当的金额。

第二个，“preauth”，保留卡上的钱，但在执行额外的“捕获”交易之前不取钱。加入这一步，可以在正式充卡前确认预授权充值。如果收费无效，也可以解除卡上的冻结。

在我的例子中，我正在立即进行“捕获”交易，但会计师可以批量“捕获”当天所有的“preauth”。

【讨论】：