【问题标题】:How could I go about signing a response from API Gateway and Lambda?我该如何签署来自 API Gateway 和 Lambda 的响应?
【发布时间】:2016-07-02 04:55:20
【问题描述】:

我们正在设计一款 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 上不可用的客户端。

【问题讨论】:

    标签: json amazon-web-services lambda aws-api-gateway serverless-framework


    【解决方案1】:

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

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

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

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

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

    【讨论】:

    • 是否可以期待来自服务器的特定证书?在客户端想要拦截流量并对其进行修改的情况下,通常很容易信任备用根证书,然后在运行中对修改后的请求进行签名
    • 如果它是您的 SSL 证书,或者您可以控制的证书,那么您就会知道 certificate thumbprint,它在所有实际用途中都不会被篡改。如果您使用像 https://example.execute-api.us-east-1.amazonaws.com/ 这样的通用端点,那么信息应该仍然相当一致且可预测,但不可否认的是您无法控制。
    【解决方案2】:

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

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

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

    然后在我的代码中:

    callback(null, JSON.stringify(data));
    

    【讨论】:

      猜你喜欢
      • 2018-06-03
      • 2022-01-21
      • 2015-12-04
      • 2019-06-04
      • 1970-01-01
      • 2015-10-21
      • 2021-10-13
      • 1970-01-01
      • 2023-03-08
      相关资源
      最近更新 更多