gRPC 通信框架實現存在數據泄露等安全問題
gRPC 是一個高性能、開源和通用的 RPC 框架，面向移動和 HTTP/2 設計。目前提供 C、Java 和 Go 語言版本，分別是：grpc, grpc-java, grpc-go. 其中 C 版本支持C, C++, Node.js, Python, Ruby, Objective-C, PHP 和 C# 支持。
當前企業正在慢慢改用微服務架構來構建面向未來的應用程序，微服務使企業能夠有效管理基礎架構，輕松部署更新或改進，并幫助IT團隊的創新和學習。它還可以幫助企業能夠設計出可以輕松按需擴展的應用程序，此外，隨著企業轉換架構(從傳統的單片式服務過渡到微服務)，出現了在微服務之間進行有效通信的需求?？蛻舳撕头掌鲬贸绦蛑g的這種關鍵而復雜的通信可以通過gRPC來處理，該框架促進了已連接系統之間的透明和高效的通信。盡管它很新(僅在2015年由Google開發)，但它很快就獲得了普及和采用。
在此文中，趨勢科技將討論開發人員在轉向gRPC并在其項目中實現gRPC時可能面臨的安全隱患。由于安全的gRPC API在整個應用程序安全中起著至關重要的作用，因此趨勢科技提供了有關如何保護gRPC實施免受威脅并緩解風險的建議。
什么是gRPC?
gRPC可用于設計要求準確性、效率和語言獨立性的新協議，因為它支持服務器和客戶端的多種語言。這是一個云原生計算(CNCF)項目，并已被各大公司采用，例如流行的視頻流網站Netflix，金融服務公司Square和平臺即服務(PaaS)公司Docker。
將gRPC與其他RPC框架(例如SOAP和REST)進行了比較，盡管RESTful API被廣泛使用，并且通常使用HTTP在應用程序或服務與JavaScript Object Notation(JSON)數據格式之間交換信息，但是它們具有性能和基于文本的方向限制。
許多組織已經將其API從REST遷移到gRPC，以利用更適合于服務間通信的gRPC二進制協議。默認情況下，gRPC使用HTTP / 2(基于二進制的協議)作為底層， HTTP / 2在一個TCP連接中支持多個流和請求，與其之前的HTTP / 1.0不同，HTTP / 1.0被設計為具有“單一請求，單一應答”方案。HTTP/1.1中的HTTP管道解決了這個問題，HTTP 2.0仍然具有更好的性能和更受支持。
HTTP / 1.0與HTTP / 2在請求和響應方面的不同之處
gRPC建立在協議緩沖區(或protobuf)之上，后者是Google的平臺和語言無關的機制，用于序列化結構化數據。序列化是將內存中的對象轉換為字節流的過程，可以輕松地將其保存到文件中或通過網絡傳輸給其他應用程序。開發人員只描述一次數據接口，然后使用用于所選語言的協議緩沖區編譯器對其進行編譯。對于gRPC，協議緩沖區也用于定義RPC接口。
gRPC框架如何在在線零售應用程序中工作的圖示，該產品具有通過API進行交互的產品和支付服務
發送字符串消息的gRPC“ HelloWorld”演示示例
gRPC的潛在威脅和風險
漏洞
gRPC支持多種編程語言，支持的語言中使用兩種類型的實現：使用語言本身的實現，以及封裝gRPC C-core編寫的代碼。這些封裝程序可以將以不同支持的語言編寫的調用轉換為C調用。盡管C語言實現通?？梢院芎玫貓绦?，但由于需要實現更多功能以及內存管理功能，因此開發人員將漏洞引入系統的可能性更高。另一方面，使用諸如Java或Go之類的語言，這些語言已經實現了很多功能，并且還考慮了內存管理問題，這降低了開發人員向系統中引入嚴重影響的漏洞的機會。值得注意的是，選擇合適的語言的重要性可能在保持系統更安全方面起著重要作用。
注意：1.可以使用純C#實現或圍繞C的C#封裝程序;2.純JavaScript實現以及與gRPC C-core的綁定(使用C ++附加組件)
不安全的數據傳輸通道和通道憑證
在遠程過程調用期間，數據很可能會傳輸到目標服務器。這就是為什么開發人員應優先考慮為數據傳輸設置安全通道。這樣做不僅可以防止數據泄漏，而且可以限制中間人(MiTM)攻擊，因為熟練的攻擊者可能會泄漏服務數據或向連接中注入惡意數據，這將干擾服務器。
數據泄漏可能會泄露有關你的服務或基礎結構的實施詳細信息，從而可能引發進一步的攻擊，甚至導致服務或基礎結構受到攻擊。這是從不安全的gRPC調用捕獲數據包的示例：
從不安全的gRPC調用捕獲數據包的示例
gRPC在整個基礎HTTP / 2協議以及各種身份驗證機制上支持TLS，選擇安全的實施是開發人員的責任。出于明顯的原因，應避免使用諸如“InsecureChannelCredentials”之類的關鍵字進行復制和粘貼模式。
趨勢科技已經執行Github.com代碼搜索“InsecureChannelCredentials”關鍵字以及C ++語言限制(這是gRPC使用的常見限制)。搜索產生了超過11000個代碼結果。趨勢科技相信大量的搜索事件與演示和示例相關。但是，仍然有一些項目使用它們。
“InsecureChannelCredentials”代碼搜索結果
程序執行漏洞
同樣，對于AWS Lambda函數，最大的漏洞隱藏在實際的遠程過程實現中。因為gRPC支持多種語言，所以趨勢科技建議新手開發人員使用內存安全的語言，以避免嚴重影響內存管理的漏洞，如緩沖區溢出或導致遠程代碼執行(RCE)的UaF 漏洞。
但是，使用內存安全語言仍然無法緩解代碼中可能出現的邏輯漏洞。為此，開發人員應為開發流程設置高標準，始終遵循安全軟件開發最佳實踐，并通過使用OWASP安全編碼實踐中的OWASP十大主動控制建議來實施主動控制。
即使在隔離的網絡或私有云內部，也強烈建議對系統的關鍵部分使用集中式身份驗證機制。在配置錯誤的情況下，環境內部的漏洞利用可能作為未授權訪問的入口點，這可能嚴重干擾gRPC服務。
趨勢科技還建議不要將gRPC身份驗證詳細信息硬編碼或提交給供應鏈管理(SCM)系統，尤其是面向公眾的系統。與其他任何憑據信息一樣，這些憑據信息應存儲在安全的位置，并且僅在需要時才進行訪問。這是一個gRPC憑證泄漏的示例，趨勢科技只是通過在GitHub上進行搜索而發現的：
在GitHub上找到的gRPC服務憑證示例
拒絕服務攻擊
最后，我們想討論趨勢科技的拒絕服務(DoS)攻擊發現。 gRPC可以充當隔離環境中的“隱藏”消息服務，以及使用JSON格式的API替代面向公眾的REST API服務。
在此，趨勢科技想警告C / C ++ gRPC用戶一個已知的但仍未修復的漏洞，該漏洞會在服務重新啟動之前有效地拒絕服務調用。在短時間內打開大量連接時會觸發該漏洞。實際上，這是由于Linux系統上打開的文件描述符的數量受到限制。
gRPC庫的C / C ++實現內部的DoS攻擊示例
根據我們的研究，當套接字連接在很短的時間內被打開，甚至在打開的套接字被關閉之后，這個漏洞就會被觸發。趨勢科技用Java和Go等非C語言封裝的其他語言測試了此實現，發現它們不受此漏洞的影響。
趨勢科技提出了以下變通辦法，以幫助緩解在無法從一個平臺切換到另一個平臺的情況下發生DoS攻擊的風險：
1.通過執行“sudo ulimit -n extendedNumber”來增加文件描述符的限制。
2.使用外部載荷平衡器和服務監視器可以減少單個實例的載荷并關注服務狀態。
針對gRPC的安全建議
由于gRPC框架服務的可靠性和可伸縮性，使用該框架的企業數量不斷增加，因此應該有更廣泛的認識來保護該協議免受攻擊風險和威脅。
盡管gRPC支持系統之間的高效通信，但必須強調的是，確保這些系統之間的通信安全是開發人員的責任。 gRPC提供了有關受支持的身份驗證機制的全面指南，該機制將與該協議一起使用，例如開發人員應遵循的使用SSL / TLS(具有或不具有基于Google令牌的身份驗證)的協議。另外，開發人員還可以選擇通過Credentials插件API插入自己的身份驗證系統。
開發人員還應該使用能夠驗證內容的安全解決方案，以確保沒有惡意負載能夠通過從客戶機到服務器的消息滲透到系統中，反之亦然。
對于企業來說，確保關鍵數據在傳輸過程中保持安全、密切關注服務狀態并實施身份驗證和授權以確保數據安全的解決方案也至關重要。
gRPC框架是開發人員和企業構建API，應用程序和微服務的有效工具。但是，像它的前任一樣，它同樣可以不受風險和威脅的侵害。因此，應該強調安全解決方案、檢查和控制的必要性。
本文翻譯自：https://blog.trendmicro.com/trendlabs-security-intelligence/unsecure-grpc-implementations-compromise-apis-applications/如若轉載，請注明原文地址。
