跳到主要内容

8. 安全注意事项

8. 安全注意事项 (Security Considerations)​

same-origin policy 是许多 user agent (包括 Web 浏览器) 安全性的基石之一. 历史上, 一些 user agent 尝试过其他安全模型, 包括 taint tracking 和 exfiltration prevention, 但这些模型当时被证明难以实现 (尽管近期又有人对复兴其中一些想法产生兴趣).

评估 same-origin policy 的安全性很困难, 因为 origin 概念本身在安全格局中扮演着核心角色. 抽象的 origin 本身只是一个隔离单元, 与大多数一刀切概念一样并不完美. 即便如此, 它仍存在一些系统性弱点, 如下所述.

8.1 对 DNS 的依赖 (Reliance on DNS)​

在实践中, same-origin policy 的安全性依赖 Domain Name System (DNS), 因为许多常用 URI scheme (例如 http) 使用基于 DNS 的命名授权机构. 如果 DNS 被部分或完全攻破, same-origin policy 可能无法提供应用所需的安全属性.

某些 URI scheme (例如 https) 对 DNS 攻破更具抵抗力, 因为 user agent 会采用证书等其他机制来验证从这些 URI 获取的内容来源. 其他 URI scheme, 例如 chrome-extension URI scheme (见 [CRX] 第 4.3 节), 使用基于公钥的命名授权机构, 因而完全不受 DNS 攻破影响.

Web origin 概念会隔离从不同 URI scheme 获取的内容; 这对于限制 DNS 攻破的影响至关重要.

8.2 不同的隔离单元 (Divergent Units of Isolation)​

随着时间推移, 多种技术逐渐将 Web origin 概念作为一种方便的隔离单元. 然而, 今天使用的许多技术 (例如 cookies [RFC6265]) 早于现代 Web origin 概念. 这些技术通常具有不同的隔离单元, 从而导致漏洞.

一种替代做法是只使用 "registry-controlled" domain 作为隔离单元, 而不是使用 fully qualified domain name (例如使用 "example.com" 而不是 "www.example.com"). 这种做法由于多种原因存在问题, 因而不推荐 (NOT RECOMMENDED):

  1. "registry-controlled" domain 的概念是围绕 DNS 的人为实践产物, 而不是 DNS 本身的属性. 例如, 日本许多市政机构在 DNS 层次结构中相当深的位置运行公共注册表. 虽然存在广泛使用的 "public suffix list", 但这些列表很难保持最新, 并且在不同实现之间存在差异.

  2. 这种做法与不使用基于 DNS 的命名授权机构的 URI scheme 不兼容. 例如, 如果某个 URI scheme 使用公钥作为命名授权机构, 那么 "registry-controlled" public key 的概念就有些不连贯. 更糟的是, 某些 URI scheme (例如 nntp) 使用与 DNS 相反方向的点分委派 (例如 alt.usenet.kooks), 另一些 scheme 虽然使用 DNS, 但以通常顺序的反向呈现 label (例如 com.example.www).

最好的情况下, 使用 "registry-controlled" domain 也是特定于 URI scheme 和实现的. 最坏的情况下, URI scheme 和实现之间的差异可能导致漏洞.

8.3 环境权限 (Ambient Authority)​

使用 same-origin policy 时, user agent 会基于内容的 URI 授予内容权限, 而不是基于该内容可以指称哪些对象授予权限. 这种将 designation 与 authority 分离的做法是 ambient authority 的一个例子, 可能导致漏洞.

例如考虑 HTML 文档中的 cross-site scripting. 如果攻击者能够将脚本内容注入 HTML 文档, 这些脚本将以该文档 origin 的权限运行, 可能允许脚本访问敏感信息, 例如用户的医疗记录. 然而, 如果脚本权限被限制为脚本能够指称的那些对象, 那么攻击者将脚本注入第三方托管的 HTML 文档并不会获得任何优势.

8.4 IDNA 依赖和迁移 (IDNA Dependency and Migration)​

same-origin policy 的安全属性可能关键依赖 user agent 所采用 IDNA 算法的细节. 特别是, 根据 user agent 使用 IDNA2003 [RFC3490] 还是 IDNA2008 [RFC5890], 它可能会将某些国际化域名 (例如涉及 U+00DF 字符的域名) 映射到不同的 ASCII 表示.

从一种 IDNA 算法迁移到另一种算法可能会重新绘制多个安全边界, 可能建立新的安全边界, 或更糟的是, 拆除两个彼此不信任实体之间的安全边界. 改变安全边界是有风险的, 因为将两个彼此不信任的实体合并到同一个 origin 中, 可能允许其中一方攻击另一方.

最后于 更新