Power Pages 安全常见问题

Power Pages 如何帮助防范点击劫持?

点击劫持使用嵌入式 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 加密板的持续评估,我们将弃用这些密码。

详细信息:哪些 TLS 1.2 密码套件受 Power Pages 支持?

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 安全白皮书