我該如何去簽署API Gateway和Lambda的響應？

我們正在設計一款iOS遊戲，其中一些用戶可能會修改從無服務器創建的後端回來作弊的響應（通過MITM僞證書）。爲了在一定程度上抵消這一點，我們希望簽署一份很難理解的簽名。這個實現全部完成（並且在Serverless-Offline上工作，但由於API網關的限制，我們很難從Lambda返回原始JSON，因此我們需要能夠獲得JSON的快照以確保當我們進行校驗和時，字符串化版本的順序是相同的，否則，它可能會在iOS端進行不同的計算，在這種情況下，它已經是一個字符串，然後被充入對象中。返回一個字符串，並沒有API網關逃避它我該如何去簽署API Gateway和Lambda的響應？

例如：

callback(null, flattened_json_string);

在Serverless-Offline上產生正確的響應，因爲它允許你返回一個字符串。當API網關實際上是託管，我們得到的東西逃走，如：

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

我不知道如何在這樣的塊來傳遞，但我不希望它被解析並重新字符串化和風險由於校驗和而改變的順序。

我也知道有很好的javascript框架來獲取對象的hases，但這顯然不適用於iOS上的客戶端。

來源

2016-07-02 David

經過幾個小時的工作，修復其實非常簡單。我需要將響應類型更改爲text/html，然後在返回之前進行stringify。

隨着無服務器，我設置以下

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

在我的代碼，然後：

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

來源

2016-07-02 05:16:44 David

在撰寫本文時，作者的回答了自己的問題，但也存在一些問題，影響解決方案的長期穩定性。

正確的解決方案是在編碼之前或解碼對象之後對鍵進行排序（通常以詞法順序排序），並組合規範化數據的散列（或者更好的HMAC？） - 排序的鍵和值。這使得簽名和驗證真正具有確定性。

使用錯誤的內容類型來使某件事情工作似乎有點粗略和脆弱。

另外，應該可以完全消除這個問題，從某種意義上說，應該預期特定證書由應用程序服務器提供 - 證書鎖定。具有MITM代理和僞造的SSL證書的惡意用戶在這種情況下將具有模擬應用服務器的計算不切實際的時間。

JSON Web Tokens也似乎很有希望，但也許不在問題的約束範圍內。

來源

2016-07-02 16:49:31

是否有可能期望來自服務器的特定證書？如果客戶想要攔截流量並對其進行修改，通常很容易相信替代的根證書，然後在動態簽名修改的請求 – David

如果是您的SSL證書或您控制的證書，那麼您將知道[證書指紋]（http://security.stackexchange.com/a/35694/32112），這是出於所有實際目的，不會被篡改。如果您使用的是像https：// example.execute-api.us-east-1.amazonaws.com這樣的通用端點，那麼這些信息應該仍然具有合理的一致性和可預測性，但無法控制。 –

我該如何去簽署API Gateway和Lambda的響應？

回答

相關問題