在 Azure 上開發安全的應用程式
在本文中,我們會提供您在開發雲端應用程式時應考慮的安全性活動和控制。 其中涵蓋 Microsoft 安全性開發生命週期 (SDL) 執行期間和驗證階段所要考慮的安全性問題和概念。 其目標是要協助您定義活動和 Azure 服務,以便您用來開發更安全的應用程式。
本文章涵蓋下列 SDL 階段:
- 實作
- 驗證
實作階段的重點是建立早期預防的最佳做法,以及偵測和移除程式碼中的安全性問題。 假設您是以非預期的方式來使用應用程式。 這可協助防止意外或刻意地誤用應用程式。
在您簽入程式碼之前,請先進行程式碼檢閱來提升整體程式碼品質,並降低發生錯誤的風險。 您可以使用 Visual Studio 來管理程式碼檢閱程序。
靜態程式碼分析 (也稱為「原始程式碼分析」) 會在程式碼檢閱過程中執行。 靜態程式碼分析通常是指執行靜態程式碼分析工具,尋找非執行中程式碼的潛在弱點。 靜態程式碼分析會使用污點檢查和資料流程分析等技術。
Azure Marketplace 提供的開發人員工具,可執行靜態程式碼分析並協助程式碼檢閱。
將所有輸入視為不信任,可為您的應用程式抵禦最常見的 Web 應用程式弱點。 不受信任的資料是插入式攻擊的媒介。 應用程式的輸入包括 URL 中的參數、使用者的輸入、資料庫中的或 API 中的資料,以及使用者可能操作的任何傳入內容。 應用程式在以任何方式 (包括向使用者顯示資料) 之前,應該先驗證這些資料的語法和語義有效。
在資料流程中預先驗證輸入,可確保只有格式正確的資料進入工作流程。 您應避免在資料庫中保存格式不正確的資料,或在下游元件中觸發故障事件。
封鎖清單和允許清單功能是執行輸入語法驗證的兩個一般方法:
封鎖清單功能會嘗試檢查指定的使用者輸入是否未包含「已知的惡意」內容。
允許清單功能會嘗試檢查指定的使用者輸入是否符合一組「已知良好」的輸入。 字元型允許清單是允許清單的一種形式,其中應用程式會檢查使用者輸入是否只包含「已知良好」的字元,或輸入是否符合已知的格式。
例如,這可能牽涉到檢查使用者名稱是否只包含英數字元,或只包含剛好兩個數字。
允許清單是建立安全軟體的慣用方法。 封鎖清單功能很容易發生錯誤,因為難以想出可能包含惡意輸入的完整名單。
請在伺服器上執行此工作,而不是在用戶端 (或是在伺服器和用戶端上)。
您以視覺化方式或在文件中呈現的任何輸出,都應一律進行編碼和逸出。 逸出 (也稱為輸出編碼) 可用來協助確保不受信任的資料不是插入式攻擊的媒介。 與資料驗證結合的逸出功能可提供多層式防禦,以提高系統整體的安全性。
逸出功能可確保所有項目都會顯示為「輸出」。此外,也可讓解譯器知道資料並非要執行,這可防止攻擊執行。 這是另一種常見的攻擊技巧,稱為「跨網站指令碼處理 (XSS)」。
如果您使用第三方的 Web 架構,您可以使用 OWASP XSS 防護功能提要,在網站上驗證輸出編碼的選項。
絕對不要在程式碼中「即時」建立內嵌資料庫查詢,以及將其直接傳送到資料庫。 插入您應用程式的惡意程式碼可能會導致您的資料庫遭到竊取、抹除或修改。 應用程式也可能遭人用來在裝載資料庫的作業系統上執行惡意的作業系統命令。
請改用參數化查詢或預存程序。 當您使用參數化查詢時,可以安全地從程式碼叫用程序,並將字串傳遞至該處,而不必擔心其被視為查詢語句的一部分。
Server、X-Powered-By、X-AspNet-Version 等標頭會揭露有關伺服器和基礎技術的資訊。 我們建議您隱藏這些標頭,以避免應用程式的特徵遭到竊取。 請參閱移除 Azure 網站上的標準伺服器標頭。
您的生產資料或「實際」資料不應用於開發、測試或任何其他非企業所預期的用途。 所有開發和測試資料都應該使用遮罩的 (匿名) 資料集。
這表示只有少數人可以存取您的實際資料,進而減少您的攻擊面。 這也表示只有少數員工會看到個人資料,進而消除潛在的機密洩漏風險。
若要防止暴力密碼破解及以字典為基礎的猜測,您必須實作強式密碼原則,以確保使用者建立複雜的密碼 (例如,長度最少 12 個字元及要求使用英數字元和特殊字元)。
Azure Active Directory B2C 提供的自助式密碼重設、強制密碼重設等功能,可協助您進行密碼管理。
若要防禦對於預設帳戶的攻擊,請確認所有金鑰和密碼均可取代,而且會在安裝資源後產生或取代。
如果應用程式必須自動產生密碼,請確保所產生的密碼是隨機的且具有高熵。
如果您的應用程式允許上傳檔案,請考慮為此風險活動採取預防措施。 在許多攻擊中,第一部舊是將一些惡意程式碼放入遭受攻擊的系統中。 使用檔案上傳可幫助攻擊者完成此動作。 OWASP 提供驗證檔案的解決方案,以確保您要上傳的檔案是安全的。
反惡意程式碼軟體可協助識別及移除病毒、間諜軟體和其他惡意軟體。 您可安裝 Microsoft Antimalware 或 Microsoft 合作夥伴的端點保護解決方案 (Trend MicroBroadcomMcAfeeWindows 中的 Microsoft Defender Antivirus 和 Endpoint Protection)。
Microsoft Antimalware 包含下列功能:即時防護、排程掃描、惡意程式碼補救、簽章更新、引擎更新、範例報告和排除事件收集。 您可以將 Microsoft Antimalware 和合作夥伴解決方案與適用於雲端的 Microsoft Defender 整合,以方便部署和執行內建偵測 (警示與事件)。
請勿快取瀏覽器上的敏感性內容。 瀏覽器可以儲存資訊以進行快取和記錄。 快取的檔案會儲存在資料夾中,例如若是 Internet Explorer,則會儲存在 Temporary Internet Files 資料夾內。 當您再次參閱這些頁面時,瀏覽器就會從快取內顯示這些頁面。 如果將敏感性資訊 (地址、信用卡詳細資料、社會安全號碼或使用者名稱) 顯示給使用者,這些資訊可能會儲存在瀏覽器的快取內,且可透過檢查瀏覽器快取或按瀏覽器的 [上一頁] 按鈕來加以擷取。
驗證階段需要兼顧每一方面,才能確保程式碼符合先前階段中所建立的安全性和隱私權原則。
您可以掃描您的應用程式及其相依程式庫,以識別任何已知的易受攻擊元件。 可用來執行這項掃描的產品包括 OWASP 相依性檢查、Snyk及 Black Duck。
「動態應用程式安全性測試」(DAST) 是在作業狀態中測試應用程式以找出安全性弱點的流程。 DAST 工具會在執行時分析程式,以找出安全性弱點,例如記憶體損毀、不安全的伺服器設定、跨網站指令碼處理、使用者權限問題、SQL 插入式攻擊,以及其他重要的安全性考量。
DAST 與靜態應用程式安全性測試 (SAST) 不同。 SAST 工具會在程式碼未執行時,分析原始程式碼或程式碼的編譯版本,以找出安全性缺陷。
執行 DAST 時最好有安全性專業人員的協助 (滲透測試者或弱點評估者)。 如果無法與安全性專業人員合作,您可以使用 Web Proxy 掃描器和一些訓練來自行執行 DAST。 請提早插入 DAST 掃描器,以確保您不會在程式碼中引進明顯的安全性問題。 如需 Web 應用程式弱點掃描器的清單,請參閱 OWASP 網站。
在模糊測試中,您可以故意將格式錯誤或隨機的資料引進應用程式來引發程式失敗。 引發程式失敗有助於在發行應用程式之前,發現潛在的安全性問題。
安全性風險偵測是 Microsoft 獨特的模糊測試服務,用以尋找軟體中的安全性關鍵錯誤。
在程式碼完成後檢查受攻擊面,有助於確保已考量對應用程式或系統進行的任何設計或實作變更。 也有助於確保已檢閱因變更而建立的任何新攻擊媒介 (包括威脅模型),並降低風險。
您可以藉由掃描應用程式來建立受攻擊面的圖片。 Microsoft 提供稱為 Attack Surface Analyzer 的受攻擊面分析工具。 您可以選擇許多商業動態測試和弱點掃描工具或服務,包括 OWASP Attack Surface DetectorArachni 和 w3af。 這些掃描工具會耙梳您的應用程式,並對應可透過網路存取的應用程式元件。 您也可以在 Azure Marketplace 中搜尋類似的開發人員工具。
確保您的應用程式安全,與測試任何其他功能同等重要。 讓滲透測試成為建置和部署程序的標準部分。 在已部署應用程式上排程定期安全性測試和弱點掃描,並監視開啟的埠、端點和攻擊。
來自 Secure DevOps Kit for Azure (AzSK) 的 Azure Tenant Security Solution (AzTS) 包含多個 Azure 平台服務的 SVT。 您會定期執行這些 SVT,以確保您的 Azure 訂用帳戶和組成應用程式的不同資源都處於安全狀態。 您也可以使用 AzSK 的持續整合/持續部署 (CI/CD) 擴充功能來自動化這些測試,使 SVT 可作為 Visual Studio 擴充功能。
在下列文章中,我們會建議可協助您設計和部署安全應用程式的安全性控制和活動。