Question

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

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

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

<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！

有没有办法确保这种形式不会被篡改？

Answer 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位小数的数字 - 如果没有盐，可以很容易地强制进行）。

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

Answer 2

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

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

第二个，“preauth”，暂停卡上的钱，但在进行额外的“捕获”交易之前不会拿钱。通过添加该步骤，可以在正式对卡充电之前确认预授权的充电。如果收费无效，则还可以取消卡上的保留。

在我的情况下，我正在立即进行“捕获”交易，但会计师可以一批“捕获”当天的所有“preauth”。

POST到托管服务时安全支付中的潜在漏洞

2 个答案: