Power Pages 安全性常見問題

Power Pages 如何協助防範點擊劫持風險?

Clickjacking 使用嵌入的 iFrames 或其他元件、劫持使用者與網頁的互動。
Power Pages 提供具有預設 SAMEORIGIN 的 HTTP/X-Frame-Options 網站設定,以防止點擊劫持攻擊。

其他資訊:在 Power Pages 中設定 HTTP 標題

Power Pages 是否支援內容安全原則?

Power Pages 支援內容安全性原則 (CSP)。 在 Power Pages 網站上啟用 CSP 之後,建議進行大量測試。

其他資訊:管理網站內容安全性原則

Power Pages 是否支援 HTTP 嚴格傳輸安全性原則?

根據預設,Power Pages 會支援 HTTP 至 HTTPS 重新導向。 如果已標記,請確認是否要求在應用程式服務層級封鎖。 如果不是成功的要求 (回應碼 >= 400),則會是「誤判」。

Power Pages 針對每個關鍵 Cookie 設定 HTTPOnly/SameSite 標誌。 有些非關鍵性 Cookie 未設定 HTTPOnly/SameSite,這些不應視為漏洞。

其他資訊:Power Pages 中的 Cookie

我的滲透測試報表標記為生命週期結束/過時軟體 – Bootstrap 3。 我該怎麼辦?

Bootstrap 3 上沒有已知的漏洞; 但是,您可以將網站移轉到 Bootstrap 5

Power Pages 支援哪些加密套件? 不斷向更強大加密方式邁進的藍圖內容為何?

所有 Microsoft 服務及產品都設定成使用經核准的加密套件,其順序與 Microsoft 加密委員會指示的完全相同。

如需完整清單及正確順序,請參閱Power Platform 文件

與取代加密套件相關的資訊都將透過 Power Platform 的匯入變更文件進行傳達。

為什麼 Power Pages 仍然支援被視為較弱的 RSA-CBC 密碼 (TLS_ECDHE_RSA_with AES_128_CBC_SHA256 (0xC027) 和 TLS_ECDHE_RSA_with_AES_256_CBC_SHA384 (0xC028))?

Microsoft 在選擇加密套件支援時,會權衡相對風險與客戶作業中斷。 RSA-CBC 加密套件尚未被打斷。 我們已讓他們能確保整個服務與產品的一致性,並支援所有的客戶設定,但這位於優先順序清單的底部。

我們根據 Microsoft 加密委員會的持續評估棄用加密套件。

其他資訊:Power Pages 支援哪些 TLS 1.2 加密套件?

Power Pages 如何防範分散式阻斷服務 (DDoS) 攻擊?

Power Pages 建立於 Microsoft Azure,並使用 Azure DDoS 防護來防禦 DDoS 攻擊。 啟用 OOB/協力廠商 AFD/WAF 還可以為網站增添更多保護。

其他資訊:

我的滲透測試報表標記了 CKEditor 中的弱點。 如何緩解此弱點?

RTE PCF 控制項即將取代 CKEditor。 如果您想在 RTE PCF 控制項發佈之前緩解此問題,請設定網站設定 DisableCkEditorBundle = true 以停用 CKEditor。 一旦停用,文字欄位將取代 CKEditor。

如何保護我的網站免受 XSS 攻擊?

建議您先執行 HTML 編碼,再轉譯來自不受信任來源的資料。

其他資訊:可用的編碼篩選

如何保護我的網站免受插入式攻擊?

根據預設,Power Pages 表單會啟用 ASP.Net 要求驗證功能,以防止指令碼插入式攻擊。 如果您使用 API 建立自己的表單,Power Pages 會採取多種措施來防止插入式攻擊。

  • 在處理來自表單或任何使用 Web API 的資料控制項的使用者輸入時,請確保正確的 HTML 清理。
  • 在將所有輸入和輸出資料呈現在頁面上之前,先對它們進行輸入和輸出清理。 這包括透過 Liquid/WebAPI 取得的資料或透過這些管道插入/更新到 Dataverse 中的資料。
  • 如果在插入或更新表單資料之前需要進行特殊檢查,您可以編寫外掛程式來執行以在伺服器端驗證資料。

其他資訊:Power Pages 安全性白皮書