高风险拜占庭容错系统Web客户端多源正确性校验方案问询

核心思路 #

绕开同源策略限制，通过多服务器哈希共识校验替代手动验证，同时从根源解决service worker的篡改和自动重载风险，确保客户端资源的合法性符合拜占庭容错要求。

可行方案 #

方案1：CORS + 拜占庭哈希共识校验 #

• 客户端初始化阶段，向集群内所有服务器发起跨域请求（需所有服务器配置允许客户端域名的CORS规则），获取核心资源（app.js、sw.js）的可信哈希值
• 基于BSMR的容错阈值（如集群共N台服务器，最多f台被攻陷，则需至少N-f台返回一致哈希），客户端自动筛选出符合共识要求的哈希作为可信基准
• 客户端从任意服务器获取资源后，用Web Crypto API本地计算哈希，与可信基准比对，一致才执行/加载；不一致则直接终止并提示用户

方案2：硬编码根哈希 + 分层校验 #

• 将客户端核心资源的根哈希（如app.js的SHA-256值）硬编码到极简版app.html中（这个HTML仅保留加载app.js的标签和内联校验脚本，尽可能缩小攻击面）
• 客户端加载后，先通过内联脚本用Web Crypto API验证app.js的哈希是否匹配根哈希，验证通过再执行app.js
• app.js启动后，向多台服务器请求sw.js的哈希，同样用拜占庭共识逻辑校验，仅当超过阈值的服务器返回一致哈希时，才下载并验证sw.js，通过后再安装
• 针对service worker的24小时强制重载：修改sw.js的更新逻辑，每次触发更新前，先向多台服务器校验新版本sw.js的哈希，只有通过共识校验才更新，否则沿用本地可信版本

方案3：本地启动极简入口 + 多源资源比对 #

• 提供给用户一个仅含核心校验逻辑的极简app.html（可让用户手动保存到本地），从本地启动客户端
• 本地客户端向所有集群服务器请求完整的app.js和sw.js资源，通过比对多份资源的一致性（结合哈希校验），筛选出符合拜占庭容错要求的可信资源
• 后续所有资源加载都基于本地缓存的可信版本，仅在用户主动触发更新时，才重新执行多源校验流程

关键细节处理 #

• 所有哈希和资源传输必须使用HTTPS，防止中间人篡改
• 核心校验逻辑（如哈希比对、共识判断）必须放在内联脚本中，避免依赖外部资源导致逻辑被篡改
• 若集群服务器使用不同域名，需确保所有服务器配置正确的CORS响应头，允许客户端跨域获取哈希和资源

内容的提问来源于stack exchange，提问作者Matteo Monti