网站开发服务内容公众号开发者绑定

网站开发服务内容,公众号开发者绑定,做什么网站比较受欢迎,推广方式当前互联网时代#xff0c;网页是最强大的应用平台。只要在浏览器中拥有合适的 API#xff0c;你理论上可以安全运行任何你想运行的东西。不过——除了“加密学”这块。事实上#xff0c;自 2011 年以来#xff0c;“网页中的 JavaScript 加密”一说就被认为是“不靠谱”的…当前互联网时代网页是最强大的应用平台。只要在浏览器中拥有合适的 API你理论上可以安全运行任何你想运行的东西。不过——除了“加密学”这块。事实上自 2011 年以来“网页中的 JavaScript 加密”一说就被认为是“不靠谱”的。 其核心问题在于代码的分发。如果我们在客户端浏览器中生成密钥从而让用户能够发送接收端对端加密消息那么如果应用被篡改恶意者究竟有什么阻止他们修改 JavaScript 代码并将消息外泄呢相比之下智能手机应用商店在这方面做得比较完善它们为应用生态提供了完整性保障确保所交付的应用未被篡改、一致性保障确保所有用户获取的是同一个版本以及透明性保障可见的版本记录。如果我们能让网页也具备类似属性——也就是无需集中式应用商店也能为网页应用提供“完整性”、“一致性”、“透明性”保障那么对于网页中运行的加密、钱包、投票系统、机密 LLM 等都会大有裨益。本文将介绍一个名为 Web Application Integrity, Consistency, and TransparencyWAICT的方案Cloudflare 参与了其起草这是一个由浏览器厂商、云服务商、加密通信应用开发者联合推动、在 W3C 拥有支持背景的项目。我们将先从问题定义谈起再逐步构建解决方案。一、定义“网页应用”在谈安全保障之前首先必须明确“网页应用web application”是什么。智能手机上的应用可以看作一个压缩包(zip)网页则由相互关联的资源组成——HTML、JavaScript、WASM、CSS 等这些资源既可能来自本域也可能来自外域而任一资源变化都可能大幅改变应用行为。因此一个连贯的“应用”定义就要求应用必须对其所加载的资源做出承诺commit。也就是说需要有机制让浏览器知道“这是这个应用应该加载的资源集合”。下面我们先从“完整性Integrity”谈起。二、完整性从 SRI 到 “完整性清单”2.1 子资源完整性Subresource Integrity, SRI网页的一个重要机制是 SRI浏览器允许页面在 script、link 等标签中指定外部资源的哈希。示例如下script srchttps://cdnjs.cloudflare.com/ajax/libs/underscore.js/1.13.7/underscore-min.jsintegritysha512-dvWGkLATSdw5qWb2qozZBRKJ80Omy2YN/aF3wTUVC5D1eqbATjWpPpoj8vorK5xGLMa2ZqIeWCpDZP/pQGQ/script浏览器会下载 underscore.js然后校验其 SHA-512 哈希是否与 integrity 属性中的值匹配匹配则加载否则抛错、不执行。如果页面中所有外部脚本、样式等资源都带有 SRI 属性那么整个页面就可被其 HTML 定义。这距离我们想要的状态已经很接近了。但网页应用通常包含多个页面并且页面之间还可能相互链接。换句话说页面无法强制其链接的“下一个页面”的哈希。2.2 完整性清单Integrity Manifest为了让整个站点域下的每个资源都受到完整性保障WAICT 提出了“完整性清单”的机制站点向客户端提供一个 JSON 配置文件manifest其内容包括一个“哈希字典hashes”将资源的哈希值映射到其路径。路径为空字符串表示“任意路径下可能的资源”例如错误页。示例如下hashes: {81db308d0df59b74d4a9bd25c546f25ec0fdb15a8d6d530c07a89344ae8eeb02: /assets/js/main.js,fbd1d07879e672fd4557a2fa1bb2e435d88eac072f8903020a18672d5eddfb7c: /index.html,5e737a67c38189a01f73040b06b4a0393b7ea71c86cf73744914bbb0cf0062eb: /vendored/main.css,684ad58287ff2d085927cb1544c7d685ace897b6b25d33e46d2ec46a355b1f0e: ,f802517f1b2406e308599ca6f4c02d2ae28bb53ff2a5dbcddb538391cb6ad56a: }一个“完整性策略integrity-policy”指定哪些类型的数据被强制检查、如何检查。例如integrity-policy: blocked-destinations(script), checked-destinations(wasm)将二者合起来后完整的 manifest 结构类似manifest: {version: 1,integrity-policy: ...,hashes: ...}有了 SRI 完整性清单那么整个站点及其浏览器端所加载的资源集合就由这个清单的哈希唯一决定。也就是说整个网站的状态可被一个哈希值所承诺。三、一致性与透明性公开、可监控的日志机制3.1 透明性的意义“透明性Transparency”指的是应用的代码资源被记录在一个公开可访问、只增不删的日志中。这样做有两方面好处如果用户被服务到恶意的代码且其察觉到了他们可以向外部证明自己运行的是什么。即便用户没有察觉外部审计者也可能在历史日志中发现恶意代码。注意透明性不能防止恶意代码的分发但至少使其可审计。现在由于我们已把整个站点状态浓缩为一个哈希我们就可以让这个哈希进入一个公开日志。以下是我们设计时应满足的重要要求不破坏已有站点 — 应可选择性启用不影响现有网站功能。不增加额外往返round-trip网络请求。尊重用户隐私不得要求用户向新第三方识别认证。用户无需保存站点特定数据无状态客户端。无中心化不能有单点失败、单点信任。启用门槛低站点运营方可以轻松加入日志。停用也容易站点可以退出日志机制。停用透明化也要可被察觉攻击者不能悄悄退出机制。监控功能站点运营方应能监控其透明化状态。3.2 哈希链Hash Chain日志通常实现为追加append-only结构支持“包含证明inclusion proof”与“一致性证明consistency proof”。最简单的追加结构即哈希链每个新元素的哈希被串联进链中最终链哈希代表整条链。image通过哈希链即可构建包含证明和一致性证明。3.3 为网站构建透明机制每站日志Per-Site Log首先为每个参与透明化的站点单独建立一个日志哈希链。该日志中的条目即该站点在某时刻的完整性清单manifest哈希。image但仅有日志还不够因为日志运营方若为恶意方仍可随意“新增删除”条目并重新计算哈希链。为防止这种情况我们引入“见证者witness”角色见证者验证日志一致性证明并对新的链哈希进行签名。客户端浏览器在用户访问站点时会收到该站点当前的 manifest 该 manifest 在站点日志中的包含证明见证者对日志链哈希的签名。 浏览器验证签名、验证包含证明、再执行完整性检查。此时用户可较为确知该 manifest 已被记录在日志中且日志没有被篡改删除。透明服务Transparency Service为了维护所有参与透明化的站点记录我们使用一个前缀树trie结构将「域名 → 站点日志链哈希 链大小 资源托管地址」做映射。image站点加入更新退出透明体系时都会在该前缀树中更新其条目。见证者需验证该前缀树更新证明并对根哈希进行签名。当用户访问站点时浏览器除了验证站点日志、还要验证站点日志是否在前缀树中包含、前缀树根签名是否可信。此外为满足“无额外往返请求”这一要求浏览器可预装一个「透明预加载列表transparency preload list」其中列出已参与透明体系的站点域名。若站点出现在此列表中则必须提供包含证明或非包含证明证明其已退出。监控、可退出、无单点监控前缀树叶节点新增了 “created” 时间戳站点运营方仅需监控“创建时间”和“日志条目数”即可判断是否被篡改。退出透明体系站点提出退出时叶节点不是直接删除而是置为“墓碑tombstone”形式保留创建时间。无单点体系设计支持多个透明服务见证者“非中心化”以减少信任或失败依赖。image四、一致性挑战树不一致与时间不一致4.1 树不一致Tree Inconsistency如果多个透明服务的前缀树对某个站点记录不一致即链哈希不同就构成“树不一致”。一种极端解决办法是让客户端要求多个服务的包含证明但这样增大负担。方案是限制透明服务的数量类似于 Google Chrome 中采用的证书透明度日志数量约为8条。4.2 时间不一致Temporal Inconsistency时间不一致指用户可能因为地域、cookie 等因素访问到较新的或较旧版本的站点。理论上如果签名有效期过长如十年站点可能一直提供非常旧的版本而用户不察。虽然最强一致性所有用户同时看到完全相同版本难以实现但我们可以降低版本分叉的规模。比如令见证者签名根哈希的有效期较短例如一周以限制可服务的版本数量。缺点是站点即便未更新也需周期性向透明服务请求新的签名。五、超越「完整性一致性透明性」其他增强特性5.1 代码签名Code SigningWAICT 本身并不解决“代码来自何处”的问题即来源可追溯性。例如Alice 自己托管一个开源软件版本Bob 如何确定其与官方仓库一致为此与 WEBCAT由 Freedom of the Press Foundation协议整合允许站点在 manifest 中加入扩展字段 dev-ids列出已签名站点资产的开发者身份例如通过 Sigstore。浏览器插件可读取该字段从而建立信任。5.2 冷却期Cooldown机制攻击者若想悄然退出透明体系或更换签名开发者身份可借助短期停顿。在预加载列表中注册的站点客户端可要求“若站点出现该名单中则必须为透明启用状态或其退出状态须已达冷却期如 24 小时之后才接受”。这样攻击者若突然切换状态将被检测。六、部署考量各角色的信任与资源需求如下透明服务Transparency Service存储所有透明化站点的元数据。若有 1 亿域名、每条256 B数据则单棵前缀树约 26 GB不含中间哈希。运营方需具备高可用性且多个服务应无关联宕机。见证者Witness验证前缀树更新、签名根哈希。存储需求类似需要高可用性并长期保管签名私钥。资源托管方Asset Host存储实际代码资源。信任要求低因为浏览器已通过哈希校验。但托管方不能篡改内容仅可能拒绝服务。客户端Client即浏览器执行所有检查包含证明、签名、完整性等是最需要信任的部分。Cloudflare 表示愿意在该生态中提供透明服务及见证者角色但会避免“自我见证”以防利益冲突。支持替代生态系统对于如 Tor Browser 这样的匿名环境可能不能信任现有透明服务。WAICT 支持将前缀树托管到区块链上以满足无中心化、无需传统域名验证的环境需求。七、下一步与总结目前 WAICT 仍处于标准化的早期阶段。下一步重点包括扩展 SRI 支持更多数据类型例如 WASM、图片标准化完整性清单格式标准化附加特性如代码签名、冷却机制我们鼓励开发者关注透明规范草案、参与讨论、提交 PR 或 Issue规范开源于 GitHub八、小结为什么这对你我很重要