應用程式生命週期威脅

Tauri 應用程式在應用程式生命週期的不同時間點由許多部分組成。在這裡，我們描述了典型的威脅以及您應該如何應對它們。

所有這些不同的步驟在以下章節中描述。

Threat Stages During Development

上游威脅

Tauri 是您專案的直接依賴項，我們對提交、審查、提取請求和發佈保持嚴格的作者控制。我們盡力維護最新的依賴項，並採取行動更新或 fork 並修復。其他專案可能沒有得到如此良好的維護，甚至可能從未經過審核。

在整合它們時，請考慮它們的健康狀況，否則，您可能在不知情的情況下採用了架構債務。

保持您的應用程式更新

當將您的應用程式發佈到野外時，您也正在運送包含 Tauri 的套件。影響 Tauri 的漏洞可能會影響您應用程式的安全性。透過將 Tauri 更新到最新版本，您可以確保關鍵漏洞已修補，並且無法在您的應用程式中被利用。還要確保保持您的編譯器 (rustc) 和轉譯器 (nodejs) 為最新版本，因為經常會有一些安全問題得到解決。這對於您的一般開發系統也是如此。

評估您的依賴項

雖然 NPM 和 Crates.io 提供了許多方便的套件，但選擇值得信賴的第三方函式庫 - 或在 Rust 中重寫它們是您的責任。如果您確實使用了受已知漏洞影響或未維護的過時函式庫，您的應用程式安全性和安穩的睡眠可能會受到危害。

使用 npm audit 和 cargo audit 等工具來自動化此過程，並依靠安全社群的重要工作。

rust 生態系統的近期趨勢，如 cargo-vet 或 cargo crev，可以幫助進一步降低供應鏈攻擊的可能性。要了解您站在誰的肩膀上，您可以使用 cargo supply chain 工具。

我們強烈建議的一種做法是，始終僅從 git 中使用 hash 修訂版本（最好）或命名標籤（次好）來使用關鍵依賴項。這適用於 Rust 以及 Node 生態系統。

開發威脅

我們假設您（開發人員）關心您的開發環境。您有責任確保您的作業系統、建置工具鏈和相關依賴項保持最新並合理安全。

我們所有人面臨的一個真正的風險是所謂的「供應鏈攻擊」，通常認為是對您專案的直接依賴項的攻擊。然而，越來越多的野外攻擊直接針對開發機器，您最好正面解決這個問題。

開發伺服器

Tauri 應用程式前端可以使用許多 Web 框架開發。這些框架中的每一個通常都附帶自己的開發伺服器，該伺服器透過開放端口將前端資產暴露給本地系統或網路。這允許前端在 WebView 或瀏覽器中熱重載和偵錯。

實際上，這種連接通常既未加密也未經身份驗證。內建的 Tauri 開發伺服器也是如此，並將您的前端和資產暴露於本地網路。此外，這允許攻擊者將他們自己的前端程式碼推送到與攻擊者位於同一網路中的開發裝置。根據暴露的功能類型，這可能導致最壞情況下的裝置洩露。

您應該僅在您可以安全地暴露開發裝置的受信任網路中進行開發。如果這不可能，您必須確保您的開發伺服器對與您的開發裝置的連線使用雙向身份驗證和加密（例如 mTLS）。

強化開發機器

強化您的開發系統取決於多種因素和您的個人威脅模型，但我們建議遵循一些通用建議

永遠不要將管理員帳戶用於日常任務，例如編碼
永遠不要在開發機器上使用生產環境密鑰
防止密鑰被檢查到原始碼版本控制中
使用安全硬體令牌或類似物來降低受損系統的影響
保持您的系統更新
盡可能減少已安裝的應用程式

在 awesome security hardening collection 中可以找到更實用的程序集合。

您當然可以虛擬化您的開發環境以阻止攻擊者，但這無法保護您免受針對您的專案而不僅僅是您的機器的攻擊。

確保原始碼控制身份驗證和授權

如果您像大多數開發人員一樣工作，則使用原始碼版本控制工具和服務提供商是開發過程中的重要步驟。

為了確保您的原始碼不會被未經授權的行為者修改，了解並正確設定原始碼版本控制系統的存取控制非常重要。

此外，請考慮要求所有（常規）貢獻者簽署其提交，以防止惡意提交歸因於未受損或非惡意的貢獻者的情況。

建置時威脅

現代組織使用 CI/CD 來製造二進制工件。

您需要能夠完全信任這些遠端（和第三方擁有）的系統，因為它們有權存取原始碼、密鑰，並且能夠修改建置，而您無法可驗證地證明產生的二進制檔案與您的本地程式碼相同。這表示您可以信任信譽良好的供應商，或者在您自己控制的硬體上託管這些系統。

在 Tauri，我們提供了一個 GitHub 工作流程，用於在多個平台上建置。如果您建立自己的 CI/CD 並依賴第三方工具，請注意您未明確釘選版本的操作。

您應該為您發佈的平台簽署您的二進制檔案。雖然這可能很複雜且設定成本較高，但終端使用者期望您的應用程式可驗證地來自您。

如果加密密鑰正確地儲存在硬體令牌上，則受損的建置系統將無法洩露所涉及的簽名密鑰，但可以使用它們來簽署惡意版本。

可重現的建置

為了對抗建置時的後門注入，您需要您的建置是可重現的，以便您可以驗證當您在本地或在另一個獨立供應商處建置時，建置資產是否完全相同。

第一個問題是 Rust 預設情況下並非完全可靠地產生可重現的建置。它在理論上支援此功能，但仍然存在錯誤，並且最近在一個版本上中斷了。

您可以追蹤 rust 專案的公開錯誤追蹤器中的目前狀態。

您將遇到的下一個問題是，許多常見的前端捆綁器也不會產生可重現的輸出，因此捆綁的資產也可能會破壞可重現的建置。

這表示您預設情況下無法完全依賴可重現的建置，並且很遺憾需要完全信任您的建置系統。

發佈威脅

我們已盡力使將熱更新發佈到應用程式盡可能簡單和安全。但是，如果您失去對 manifest 伺服器、建置伺服器或二進制託管服務的控制權，則一切都將落空。

如果您要建置自己的系統，請諮詢專業的 OPS 架構師並正確建置它。

如果您正在為 Tauri 應用程式尋找另一個受信任的發佈解決方案，我們的合作夥伴 CrabNebula 提供了一個產品：https://crabnebula.dev/cloud

執行時威脅

我們假設 webview 是不安全的，這使得 Tauri 實施了多項保護措施，以防止 webview 在載入不受信任的使用者端內容時存取系統 API。

使用內容安全策略將鎖定 Webview 可以進行的通訊類型。此外，功能可以防止不受信任的內容或腳本存取 Webview 內的 API。

我們還建議設定一種簡單且安全的方式來報告漏洞，類似於我們的流程。