0

我们正在设计一个 iOS 游戏，其中一些用户可能会修改从无服务器创建的后端返回的响应以作弊（通过 MITM 假证书）。为了在一定程度上帮助抵消这种情况，我们希望包含一个很难弄清楚的签名。这个实现已经全部完成（并且在无服务器离线上工作，但是由于 API 网关的限制，我们很难从 Lambda 中返回原始 JSON。我们需要能够拥有 JSON 的快照以确保当我们进行校验和时，字符串化版本的顺序是相同的。否则，它可能在 iOS 端计算不同，在被膨胀成对象之前它已经是一个字符串。

是否有任何可能的方法来返回一个字符串而不让 API Gateway 转义它？

例如：

 callback(null, flattened_json_string);

在 Serverless-Offline 上产生正确的响应，因为它允许您返回一个字符串。当实际托管在 API-Gateway 中时，我们会得到一些逃逸的东西，例如：

"{\"metadata\":{\"cmKey\":\"537d1a54916e56bac1d03478b18575e8c0c74d86\",\"cacheReady\":true,\"serverTime\":1467433541108},\"commands\":[]}"

我确实知道传递这样一个块的方法，但我不希望它被解析和重新字符串化，并且由于校验和而冒着改变顺序的风险。

我也知道有很好的 javascript 框架来获取对象的哈希，但这显然在 iOS 上不可用的客户端。

4

2 回答 2

1

在撰写本文时，作者已经回答了他自己的问题，但存在一些影响解决方案长期稳定性的问题。

正确的解决方案是在编码之前或解码对象之后对键进行排序（通常按词法顺序），并组装规范数据的散列（或者，也许更好的是 HMAC？） - 排序的键和值。这使得签名和验证真正具有确定性。

使用错误的内容类型来使某些东西起作用似乎有点粗略和脆弱。

此外，应该可以完全消除这个问题，方法是期望应用程序服务器提供特定的证书——某种意义上的证书固定。在这种情况下，具有 MITM 代理和伪造 SSL 证书的恶意用户将有一个计算上不切实际的时间来冒充您的应用程序服务器。

JSON Web Tokens似乎也很有希望，但可能不在问题的限制范围内。

于 2016-07-02T16:49:31.067 回答
0

经过几个小时的工作，修复实际上相当简单。我需要将响应类型更改为 text/html，然后在返回之前进行字符串化。

使用无服务器，我设置了以下内容

"responseTemplates": {
        "text/plain": "$input.path('$')"
      }

然后在我的代码中：

callback(null, JSON.stringify(data));
于 2016-07-02T05:16:44.143 回答