1

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

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

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

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

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

4

2 回答 2

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 位的数字 - 如果没有盐，很容易被暴力破解）。

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

于 2012-08-16T21:01:24.227 回答
0

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

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

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

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

于 2012-08-29T17:39:46.880 回答