4. 安全考量
4. 安全考量
铸造新知名 URI 的应用以及部署它们的管理员需要考虑若干安全问题, 包括但不限于: 敏感数据暴露, 拒绝服务攻击 (除正常负载问题外), 服务器与客户端认证, DNS 重绑定 (DNS rebinding) 攻击的脆弱性, 以及对服务器仅有有限访问权限却可影响知名 URI 提供方式的攻击.
[RFC3552] 包含一些可能与应用协议及部署管理员相关的潜在安全考量示例.
4.1. 保护知名资源
由于知名位置在效果上代表整个源, 服务器运营者应适当控制对其的写入能力. 当多个实体共置于同一源上时尤其如此. 即使源由单一实体控制并代表该实体, 也应格外谨慎, 确保不会无意中通过服务器配置或在实现权限 (例如文件系统) 中授予对知名位置的写访问.
4.2. 与 Web 浏览的交互
对 http 或 https URL 使用知名 URI 的应用应意识到, 知名资源将对 Web 浏览器可访问, 因而可能被从该源其他部分获得的内容操纵. 若攻击者能够注入内容 (例如通过跨站脚本 Cross-Site Scripting 漏洞), 便可能对知名资源发起潜在的任意请求.
HTTP 与 HTTPS 还将源作为许多其他机制的安全边界, 包括但不限于 cookie [RFC6265], Web 存储 (Web Storage) [WEBSTORAGE] 以及各种能力.
定义知名位置的应用不应假定其独占这些机制或独占该源. 根据应用性质, 缓解措施可包括:
-
对敏感信息加密
-
在使用标识符 (例如 cookie 名称) 时保持灵活, 以避免与其他应用冲突
-
在 cookie 上使用
HttpOnly标志, 确保 cookie 不会暴露给浏览器脚本语言 [RFC6265] -
在 cookie 上使用
Path参数, 确保其不会对该源其他部分可用 [RFC6265] -
使用
X-Content-Type-Options: nosniff[FETCH], 确保受攻击者控制的内容无法被诱使成 Web 浏览器解释为活动内容的形态
其他良好实践包括:
-
在 Content-Type 头字段中使用应用专用媒体类型, 并要求客户端在未使用时失败
-
使用内容安全策略 (Content-Security-Policy, CSP) [CSP] 限制活动内容 (如 HTML [HTML5]) 的能力, 从而缓解跨站脚本攻击
-
使用 Referrer-Policy [REFERRER-POLICY], 防止 URL 中的敏感数据在 Referer 请求头字段中泄漏
-
避免对任何敏感信息 (例如认证令牌, 密码) 使用压缩, 因为 Web 浏览器提供的脚本环境允许攻击者反复探测压缩空间; 若攻击者可访问通信路径, 便可利用该能力恢复这些信息.
4.3. 限定应用范围
本备忘录既不规定从知名 URI 获得信息的适用范围, 也不规定如何发现某应用的知名 URI.
使用本机制的各个应用必须同时定义这两方面; 若未规定, 可能因实现差异与应用边界混淆而产生安全问题.
将知名 URI 中发现的元数据应用于非共置于同一源上的其他资源, 会带来管理与安全风险. 例如, 允许 https://example.com/.well-known/example 对 https://department.example.com, https://www.example.com 甚至 https://www.example.com:8000 施加策略, 假定了主机之间可能存在的关系, 从而可能将控制权交给潜在攻击者.
同样, 规定在特定主机名上使用知名 URI 来引导某协议可能导致大量非预期请求. 例如, 若使用知名 HTTPS URI 查找与电子邮件等独立服务相关的策略, 可能导致向 Web 服务器发起请求洪流, 即使它们并未实现该知名 URI. 此类非预期请求可能类似拒绝服务攻击.
4.4. 隐藏能力
使用知名位置的应用应考虑, 某些服务器管理员可能不了解它们的存在 (尤其在以 . 开头的目录名会被隐藏的操作系统上). 这意味着若攻击者对 .well-known 目录具有写访问权限, 便可能控制其内容, 而管理员可能毫无察觉.