Alert Source Discuss
🚧 Stagnant Standards Track: Interface

EIP-5593: 限制以太坊 Provider API 注入

钱包指南，用于限制以太坊 Provider API 访问安全上下文，以提高钱包用户的隐私和安全性。

Authors Yan Zhu (@diracdeltas), Brian R. Bondy (@bbondy), Andrea Brancaleoni (@thypon), Kyle Den Hartog (@kdenhartog)
Created 2022-09-05
Discussion Link https://ethereum-magicians.org/t/rfc-limiting-provider-object-injection-to-secure-contexts/10670
Requires EIP-1193

Table of Contents

摘要

从历史上看，Web 平台有一个“强大的”API 的概念，例如 W3C 的地理位置规范和 W3C 的媒体流规范中定义的 API，这些 API 受制于额外的安全限制，例如 W3C 的安全上下文规范中定义的那些限制。由于以太坊 Provider API 允许 dApp 网站请求访问敏感用户数据并请求使用用户资金，因此新的以太坊 Provider API 通常应符合 W3C 的安全上下文规范中定义的安全性考虑因素，以便更好地保护用户数据和通过 Web 管理的用户资金。

作者注

不幸的是，由于 EIP 编辑对 EIP-1 中链接的 RFC 2119 术语的解释存在差异，作者无法直接链接到此 EIP 所基于的其他 W3C 规范。作者试图在文本中提供尽可能多的上下文，同时遵守编辑器机器人的要求，以便将其合并。如果此政策在将来此 EIP 达到最终调用之前更新或进一步澄清，此 EIP 将使用链接进行更新。

动机

钱包通常维护用户资金的安全性和安全性，这可能相当于大量的资金。因此，最好限制对以太坊 Provider API 的访问，使其与其他 Web 平台上的强大 API 保持一致。这将有助于减少攻击面，这些攻击可能会被用来访问用户的资金或数据。此外，通过添加限制，我们减少了恶意网页可能通过以太坊 Provider API 指纹识别用户的攻击面，从而提供了一些额外的隐私优势。通过此方法避免的一个具体攻击示例是，在合法的 dApp 上加载恶意广告，该广告试图与用户的钱包交互，以恶意地请求用户访问资金。通过实施此 EIP，广告框架将被视为第三方 iframe，因此以太坊 Provider API 不会注入到其子框架中，因为它不是安全上下文。

规范

本文档中的关键词“必须（MUST）”，“不得（MUST NOT）”，“需要（REQUIRED）”，“应（SHALL）”，“不应（SHALL NOT）”，“应该（SHOULD）”，“不应该（SHOULD NOT）”，“推荐（RECOMMENDED）”，“可以（MAY）”和“可选（OPTIONAL）”应按照 RFC 2119 中的描述进行解释。

provider 的限制

符合本规范时，provider 对象（例如 window.ethereum）应仅在安全上下文中注入以太坊 Provider API。对于符合规范的钱包，以下限制是必需的（REQUIRED）：

  • Provider 对象可以（MAY）在私有（隐身）窗口中访问。
  • 来源必须是“潜在可信来源”（在 W3C 的安全上下文中第 3.1 节中定义），才能访问 window.ethereum。可以使用 window.isSecureContext 进行检查，包括在 iframe 内部。
    • 安全上下文包括通过 HTTPS 提供的站点，但也包括 HTTP localhost。
    • 用户代理实现可以（MAY）还支持配置的[潜在可信来源]，如果用户配置其用户代理这样做，这些来源通常不会被认为是可信的。有关更多详细信息，请参见 W3C 安全上下文规范的 7.2 节，标题为“开发环境”。例如，在基于 Chromium 的用户代理中，这是通过 chrome://flags/#unsafely-treat-insecure-origin-as-secure 标志完成的。
  • 默认情况下，以太坊 Provider API 不得（MUST NOT）暴露给第三方 iframe。
  • 在 window.isSecureContext 在该 iframe 中返回 false 的 iframe 中，window.ethereum 必须（MUST）为 undefined。
  • 如果 iframe 是顶级安全来源的第三方，则应（SHOULD）阻止它。
  • 如果 iframe 是顶级来源的第一方，并且在 iframe 上设置了 sandbox 属性，则必须（MUST）阻止 provider 对象。如果 sandbox 属性设置为 sandbox="allow-same-origin"，则必须（MUST）为第一方框架注入该对象。
    • 请注意，如果 iframe 是第三方，则 "allow-same-origin" 不起作用。第三方 iframe 的情况由 allow 属性和权限 API 的使用决定，如上面的规则中所定义。

理由

通过限制注入以太坊 Provider API 的能力，我们可以减少可以执行攻击的范围。鉴于传递给以太坊 Provider API 的数据的敏感性，应满足一些基本的身份验证和机密性级别，以确保请求数据不会被拦截或篡改。虽然已经有人尝试通过钱包接口本身限制请求访问，但尚未对以太坊 Provider API 的预期注入位置或不注入位置设置限制。由于安全上下文 Web 平台 API 是 W3C 推荐的完善边界，并且以太坊 Provider API 正在扩展传统的 Web 平台 API，因此没有考虑其他替代解决方案来扩展当前已建立的现有技术。

向后兼容性

钱包扩展程序应（SHOULD）考虑通过用户体验添加一个“开发者模式”切换，以便 dApp 开发者能够在仅在 http://localhost:<any-port> 来源的 localhost 未返回安全上下文的 true 时禁用不安全上下文 (http) 检查。有关更多详细信息，请参见 W3C 安全上下文规范的 5.2 节。这将允许 dApp 开发者能够在 localhost 来源上继续托管 dApp，如果用户代理选择不将 localhost 视为安全上下文。所有经过测试的主要用户代理实现都已将 localhost 视为安全上下文。此切换必须（MUST）默认设置为禁用。

测试用例

必需的测试用例

  • 顶级 http://a.com -> 阻止（不安全/顶级）
  • 顶级 https://a.com -> 允许
  • 带有 <iframe src="http://a.com/"> 的顶级 https://a.com -> 阻止（不安全的第一方 iframe）
  • 带有 <iframe src="https://a.com/"> 的顶级 http://a.com -> 阻止（不安全顶级窗口）
  • 带有 <iframe src="https://a.com"> 的顶级 https://a.com -> 允许
  • 带有 <iframe src="https://b.com"> 的顶级 https://a.com -> 阻止（没有足够权限的第三方 iframe）
  • 带有 <iframe src="http://a.com/"> 和 <iframe src="https://b.com"> 的顶级 https://b.com -> 阻止（不安全的 iframe）
  • 带有 <iframe src="https://a.com"> 和 <iframe src="https://b.com"> 的顶级 https://b.com -> 阻止（没有足够权限的第三方 iframe）
  • 带有 <iframe src="https://sub.a.com"> 的顶级 https://a.com -> 阻止（没有足够权限的第三方 iframe）
  • 带有 <iframe src="https://a.com" sandbox> 的顶级 https://a.com -> 阻止（没有 “allow-same-origin” 的 sandbox 属性）
  • 带有 <iframe src="https://a.com" sandbox="allow-same-origin allow-scripts"> 的顶级 https://a.com -> 允许（注意，用户代理实现者（例如 Mozilla 的 MDN 文档）不鼓励这种情况，因为它允许 iframe 删除自身的 sandbox 属性。有关更多详细信息，请参见 MDN 中 iframe 文档的 sandbox 属性部分。）
  • 带有 <iframe src="data://bar"> 的顶级 data://foo -> 阻止（不安全顶级方案）
  • 带有 <iframe src="file://bar"> 的顶级 file://foo -> 阻止（第三方 iframe）
  • 带有 <iframe src="https://b.com" sandbox="allow-same-origin allow-scripts"> 的顶级 https://a.com -> 阻止（没有足够权限的第三方 iframe）

安全注意事项

用户启用开发者模式

通常，开发者需要能够在本地开发 dApp，以便在 http://localhost 上托管其 dApp 时测试其网站并进行开发。在这种情况下，localhost 将被阻止，并且在本地开发 dApp 时会出现兼容性问题。为了提高 dApp 开发者的兼容性，可以考虑使用切换来禁用对 localhost 的检查。如果将其扩展到 localhost 来源之外，则可以用来说服用户启用开发者模式，以规避此 EIP 设置的保护措施。因此，在将此开发者切换扩展到 localhost 来源范围之外时，实施应谨慎。

隐私注意事项

Web3 Provider 指纹识别

由于默认情况下 provider 对象注入到大多数网页中的方式的性质，恶意网页有可能利用 provider 对象更精确地将用户指纹识别为 Web3 用户。此 EIP 的实施者应考虑默认情况下将以太坊 provider API 注入页面的风险，以便考虑他们希望为其用户启用的隐私特征。

版权

版权和相关权利已通过 CC0 放弃。

Citation

Please cite this document as:

Yan Zhu (@diracdeltas), Brian R. Bondy (@bbondy), Andrea Brancaleoni (@thypon), Kyle Den Hartog (@kdenhartog), "EIP-5593: 限制以太坊 Provider API 注入 [DRAFT]," Ethereum Improvement Proposals, no. 5593, September 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5593.