如何配置Amazon AWS Lambda函數以防止拖尾回覆中的日誌？

請看到這一點：如何配置Amazon AWS Lambda函數以防止拖尾回覆中的日誌？

http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html

日誌類型

只有在指定值爲 requestResponse則在InvocationType參數可以設置此可選參數尾巴在請求。在這種情況下，AWS Lambda返回x-amz-log-result標頭中由Lambda函數生成的最後4 KB日誌數據的base64編碼的。

有效值：無|尾

所以這意味着任何具有有效憑據調用函數的用戶也可以讀取此函數發出的日誌？

如果是這樣，這是一個明顯的漏洞，可以給一些攻擊者提供有關處理無效輸入的有用信息。

如何配置Amazon AWS Lambda函數以防止拖尾響應中的日誌？

更新1

1）關於評論：「如果黑客可以打電話給你的lambda函數，你不是看到日誌文件更多的問題」

事實並非如此：lambda函數也意味着使用SDK直接調用客戶端代碼。

舉個例子，看看下面的圖片從書「AWS LAMBDA在行動」：關於評論

2）：「這是怎麼一個漏洞恰好只有一個人，你有嗎？提供AWS IAM憑證將能夠調用lambda函數。「

當然，客戶也有一些資格證書，大部分的時間（例如，從具有與他們的Facebook帳戶登錄到您的移動應用，通過Am azon Cognito）。我應該信任我的所有用戶嗎？

3）關於評論：「只有當你把一些安全信息將被記錄。」

日誌可能包含敏感信息。我不是在談論密碼等安全信息，而只是幫助開發團隊調試的信息，或者是安全團隊發現攻擊的信息。應用程序可以記錄各種信息，包括爲什麼某些無效輸入失敗，這可以幫助攻擊者瞭解什麼是有效輸入。另外，攻擊者可以看到安全團隊記錄他們攻擊的所有信息。不好。取決於您登錄的內容，即使隱私也可能存在風險。

更新2

這也將解決我的問題，如果我能以某種方式檢測拉姆達代碼Tail參數。然後，我會以「現在允許的尾巴」消息失敗。不幸的是，Context對象似乎不包含這些信息。

來源

2017-10-18 MarcG

這完全是一個漏洞嗎？只有您提供了AWS IAM憑據的用戶才能夠通過AWS API直接調用Lambda函數。 –

（除了上面的註釋以外），並且僅限於將某些安全信息記錄爲lambda函數的輸出 – hjpotter92

此參數僅在調用API調用期間使用。如果黑客可以調用您的Lambda函數，那麼比查看日誌文件更麻煩。 –

我認爲您不能配置AWS Lambda以防止拖尾響應中的日誌。但是，您可以使用自己的日誌記錄組件，而不使用Amazon Lambda提供的日誌組件，以避免通過參數LogType公開它們。

否則，我明白你的意思是增加複雜性，但使用API Gateway是最常見的解決方案，可以爲不信任的客戶端應用程序調用Lambdas。

來源

2017-10-23 14:08:00

這是一條評論。 雖然這應該是一個評論，但我很抱歉，我還沒有足夠的計算器聲譽來這樣做。

之前評論此，請注意，拉姆達調用可能會導致（每AWS文檔）

的調用響應事件和功能發生至少一次的拉姆達的不止一個執行必須是冪等來處理這個問題。

由於LogType被記錄爲一個有效的選項，我不認爲你可以阻止它在你的後端。但是，您需要有一個解決方法來處理它。我可以想到

1-生成一個垃圾4KB尾日誌（例如console.log（））。然後，攻擊者將得到一個垃圾信息。（僅在攻擊者的情況下發生成本）

2-使用步驟功能。這不僅僅是爲了隱藏日誌，而是爲了解決'調用至少發生一次'的問題，並且有可預測的後端執行。儘管如此，它仍然帶來成本

來源

2017-10-27 00:51:36

哇，調用可能每個請求運行多次？這很糟糕。 https://www.youtube.com/watch?v=hFtUUx4Zybw&feature=youtu.be&t=15m6s – MarcG

垃圾日誌？但我想記錄我的真實信息（用於我自己的訪問）。 – MarcG

當然，你可以登錄你的信息。因此，在記錄真實信息之後，在調用context.succeed（）或callback（）之前，您需要添加一個4KB大小的日誌。但是，這不會隱藏「持續時間：xxx ms \t計費時間：xxx ms內存大小：xxx MB \t使用的最大內存：xx MB」。例如，如果您記錄了許多「A」console.log（「A .........」）的文本，則logResult將包括「BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQF .......」而不是您的信息日誌。 –

你說得對，這不僅是一種不好的做法，很明顯（正如你已經理解的那樣）引入了安全漏洞。

如果您在書中仔細看，你會發現這部分：

這也解釋了，爲了更加安全，客戶端的請求應該打亞馬遜API網關將露出清潔API接口，它將調用相關的lambda函數而不會將其暴露給外部世界。

這種API的一個例子是在先前的頁面demo'ed：

由客戶端和AWS-拉姆達之間引入中間層中，我們照顧身份驗證，授權，訪問和所有其他潛在的脆弱點。

來源

2017-10-28 16:43:50 alfasin

API網關不是免費的，並引入額外的延遲。它基本上引入了額外的不必要的步驟，並使管理變得複雜（易於管理應該是AWS-Lambda的優勢）。如果我的服務並不是要「公開一個可以被外部服務使用的乾淨的Web API」，我不明白爲什麼我只是爲了解決這個尾部問題而被迫這樣做。 – MarcG

到目前爲止，我沒有看到使用API網關的其他優點。您也可以通過直接訪問AWS-Lambdas來進行身份驗證和授權。緩存我不需要。節流也由AWS-Lambdas完成，Amazon SDK甚至會自動重試。 – MarcG

「通過直接訪問AWS-Lambdas進行身份驗證和授權」 - 這意味着您需要爲每個用戶創建IAM用戶並對其進行管理......（這需要花錢）。 – alfasin

如何配置Amazon AWS Lambda函數以防止拖尾回覆中的日誌？

回答

相關問題