Web實時通信（WebRTC）是最快的流媒體技術，但這種速度帶來了復雜性。自然，人們質疑以超低延遲傳輸媒體的流媒體方法如何能夠充分保護媒體或其傳輸的連接。但也有好消息。雖然WebRTC加密和安全性可能很復雜，但它很強大。在本文中，我們將討論WebRTC安全漏洞以及WebRTC如何解決它們。

WebRTC簡介

WebRTC不僅僅是一個協議。它是流技術的集合，包括協議、標準和三個JavaScript API。其中包括用戶數據報協議（UDP）。此連接協議與其對應協議傳輸控制協議（TCP）形成鮮明對比，因為它優先考慮速度而不是可靠性。這與WebRTC的開源性質相結合，往往會強化WebRTC是一種易受攻擊的技術的誤解，但這與事實相去甚遠。

了解WebRTC通信

在我們深入研究WebRTC安全漏洞以及它如何解決這些漏洞之前，讓我們探討一下WebRTC如何創建和維護媒體傳輸的連接。人們會經常提到“WebRTC協議”，但正如我們上面提到的，WebRTC并不是嚴格意義上的協議。它是技術的集合，包括三個JavaScriptAPI，它們協同工作以建立和維護對等體和傳輸介質之間的連接。

獲取用戶媒體

getUserMediaAPI幾乎完全符合它的聲音。它從他們的網絡攝像頭和麥克風獲取用戶的媒體。曾幾何時，這是使用Flash等第三方插件完成的，但是HTML5通過引入此API改變了游戲規則。WebRTC很高興地利用它作為其底層技術的一部分。

RTCPeerConnection

RTCPeerConnection是一個特定于WebRTC的API，它使用會話描述協議（SDP）在對等方之間建立連接。它還負責對媒體進行編碼，并使用UDP 通過已建立的連接發送媒體。

RTCDataChannel

最后，還有RTCDataChannelAPI。此 API處理非音頻/視頻形式的數據。它負責通過RTCPeerConnection建立的連接傳輸文本和其他替代類型的數據。

從技術上講，這些以及您訪問WebRTC應用程序的瀏覽器是成功流式傳輸所需的全部內容。但是，這通常不是可擴展的解決方案。許多人最終將這種所謂的無服務器技術與一系列服務器一起使用，以促進通信和可擴展性。正如我們將在下一節中探討的那樣，這引入了一些額外的安全問題。

WebRTC安全漏洞和注意事項

WebRTC要求在協議級別進行加密。在瀏覽器環境中運行時，它受到嚴格的隱私和安全控制，但是不使用瀏覽器的服務呢？雖然WebRTC主要是為瀏覽器到瀏覽器的通信而設計的，但它經常使用各種基礎設施設備，這可能會使其安全性復雜化。下表總結了常見的WebRTC服務器類型及其高級安全隱患。

固有的互聯網安全問題

WebRTC信令服務器本質上是Web應用程序服務器，需要像任何應用程序一樣進行保護。用戶應警惕他們連接到誰。幸運的是，瀏覽器和應用商店保護措施最大限度地減少了不良提供商-但不良用戶是另一個問題?！翱s放轟炸”是指獲取視頻會議會議信息以未經授權加入會議，通常用于破壞性目的。WebRTC服務提供商可以通過為其用戶提供身份驗證機制來防止這種情況，這些機制將訪問權限限制為授權用戶，并利用審核控制來快速刪除和阻止不良行為者。例如，Wowza具有控制WebRTC流訪問和持續時間的API。

媒體服務器風險

雖然有時需要STUN和TURN等其他服務器，但這些服務器永遠無法訪問未加密的媒體，因此不會帶來太大的風險。其他服務器，尤其是支持多方視頻電話會議或實時流媒體服務器的選擇性轉發單元（SFU）等媒體服務器，會帶來更困難的風險。這些服務器在使用新的加密密鑰重新傳輸媒體之前解密媒體。這種解密通常是無法避免的。如果媒體服務器需要操作媒體，則必須執行解密才能訪問該媒體。例如，在實時流網絡中，媒體服務器需要解密媒體以對其進行轉碼（調整大小、重構和轉換格式），以供內容分發網絡（CDN） 使用。

如果這些媒體服務器遭到入侵，則用戶媒體流可能會面臨風險。媒體服務器運營商在部署其基礎結構和管理授權用戶時遵循最佳安全實踐非常重要。因此，這些服務器應避免意外緩存敏感的未加密數據。此外，他們應該在內部將媒體流與其他進程隔離，以進一步避免未經授權的訪問。

安全性應特定于應用程序。例如，您可能需要錄制和存檔媒體以進行有意分發。在這種情況肯定需要保存到磁盤并至少使其在某種程度上可用。安全措施應規定如何以及由誰完成。他們還應該確定誰可以訪問和播放媒體。

審核編輯 ：李倩