Buzz 安全白皮书NIP-42/NIP-98 认证、频道成员授权与防篡改审计链的设计与实践【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz本文基于 SECURITY.md 官方安全策略展开结合仓库源码逐层剖析 Buzz 的安全设计从漏洞披露流程与版本支持策略到 NIP-42/NIP-98 双重认证路径、以频道成员身份为唯一闸门的授权模型、基于 SHA-256 链的追加式审计日志、桌面端密钥库迁移机制再到 SSRF 防护与依赖供应链治理。读完你将获得一套可直接落地的 Nostr 中继安全基线并能定位到对应的 Rust 实现与测试验证。一、漏洞报告与协调披露流程1.1 私密上报禁止公开渠道Buzz 的安全策略对漏洞上报渠道有严格约束不得通过公开的 issue、pull request、讨论区或其他公开渠道报告安全漏洞。正确路径是使用 GitHub 的私密漏洞上报表单提交后即与 Buzz 维护者建立私密安全公告private security advisory用于承载漏洞细节、后续问题与协同修复。若表单不可用可邮件联系buzzblock.xyz同样不得在公开 issue 中夹带漏洞细节。提交时应尽可能提供以下信息策略原文明确要求漏洞描述及其潜在影响复现步骤或概念验证PoC如可用受影响版本或 commit 范围你已识别的缓解建议。1.2 响应时限与安全期望官方承诺的响应节奏如下阶段时限确认收到48 小时内完整响应含修复时间表首次联系后7 天内同时策略要求报告者做到三点在公开披露前给予合理修复时间、不访问或修改不属于自己的数据、不对生产系统实施拒绝服务攻击或造成中断。报告者会在发布说明中被致谢除非主动要求匿名。1.3 支持范围Buzz 目前处于 pre-1.0 阶段不维护长期支持LTS分支版本支持状态main最新✅ 活跃支持之前的历史版本⚠️ 尽力而为建议升级所有安全修复首先落在main分支上。这一策略意味着部署者应持续跟踪最新主分支而不是依赖旧版本的补丁回移。二、安全设计原则总览SECURITY.md 的Security Design Principles一节是整份文档的技术核心涵盖六大支柱认证NIP-42WebSocket 挑战-响应与 NIP-98HTTP Auth授权以频道成员身份作为唯一访问控制闸门审计buzz-audit追加式 SHA-256 哈希链日志桌面端密钥存储OS 密钥库Keyring替代明文文件输入校验UUID 边界校验、SSRF 防护、响应体限长、沙箱化条件求值、参数百分号编码传输与依赖安全TLS 终止于中继或反代、cargo auditCI 扫描、全 crate 禁止unsafe。下文将逐条对应源码展开。三、认证NIP-42 与 NIP-98 双路径实现3.1 认证架构总览从 crates/buzz-auth/src/lib.rs 的模块文档可见两条认证路径的完整定义路径传输层描述NIP-42WebSocket挑战/响应客户端签署 kind:22242 事件NIP-98HTTPAuthorization: Nostr头携带 kind:27235 事件该 crate 同时声明了三条安全不变量值得部署者与集成方牢记AUTH 事件kind:22242绝不存储或记录日志——它们可能包含承载令牌bearer token所有路径最终产出一个与连接绑定的AuthContext无 JWT 校验、无令牌管理、无 IdP 运行时依赖——认证完全基于 Nostr 原生签名机制。3.2 NIP-42WebSocket 挑战-响应认证认证流程见 crates/buzz-auth/src/nip42.rs 模块文档中继发送随机挑战[AUTH, challenge]由generate_challenge生成——32 字节 CSPRNG 随机数十六进制编码后为 64 个字符客户端签署一个 kind:22242 事件携带 challenge 与 relay 标签中继通过verify_nip42_event校验签名、挑战值、中继 URL 与时间戳。校验细节体现了扎实的工程防御挑战值必须精确匹配否则返回ChallengeMismatch对应测试 wrong_challenge_rejected中继 URL 归一化比较normalize_relay_url会将localhost/::1归一化为127.0.0.1并去除尾部斜杠避免同一中继因书写差异导致认证失败见测试 localhost_and_127_are_equivalent时间戳容忍窗口 ±60 秒TIMESTAMP_TOLERANCE_SECS: u64 60超出即返回EventExpired防止重放测试 expired_event_rejected事件 kind 必须是Kind::Authentication22242否则拒绝。在异步上下文里Schnorr 验签是 CPU 密集操作因此AuthService::verify_auth_event使用tokio::task::spawn_blocking把验签移出 Tokio worker 线程见 crates/buzz-auth/src/lib.rs#L131-L156。纯 Nostr 模式下所有已认证连接获得完整作用域Scope::all_known()而逐频道权限交由中继的成员资格检查NIP-29执行——这正是下一节的授权模型。3.3 NIP-98HTTP Auth 与重放防护REST 端点使用 NIP-98 文档共八步解析 JSON 为nostr::Event校验kind 27235通过buzz_core::verify_event校验 Schnorr 签名同时校验事件 ID 哈希校验created_at在服务器时间 ±60 秒内校验[u, url]标签与期望 URL 匹配归一化scheme/host 大小写不敏感、去尾部斜杠校验[method, method]标签与期望方法匹配大小写不敏感若事件携带[payload, hash]且服务端持有请求体则校验SHA-256(body) hex(payload)防止请求体替换攻击成功时返回event.pubkey。其中几个防御细节值得关注标签基数检查u与method标签必须恰好一个payload标签至多一个。重复标签哪怕第一个合法、第二个矛盾一律拒绝——这堵住了.find()只取第一个而忽略后续矛盾标签的绕过路径测试见 duplicate_u_tag_rejected 等不做 loopback 别名合并NIP-98 的normalize_url刻意不将localhost、::1、127.0.0.1合并。在多租户场景下u标签的 host 就是社区绑定的row-zero标识若校验器把三者折叠为localhost签署的事件就能通过127.0.0.1解析的社区——这是主机绑定的侧门测试 loopback_aliases_are_distinct_hosts 用四个用例锁死了这一行为。这与 NIP-42 的归一化形成鲜明对比NIP-42 面向中继地址等价性NIP-98 面向租户隔离两者目标不同、策略相反切勿混用载荷哈希可选而非强制payload标签的存在性由各消费端在需要绑定请求体完整性的边界强制执行如管理端authorize_nip98与 bridge 的require_payloadtrue路由而/events、/query、/count等允许不带标签签署——这是共享校验器服务不同调用方的刻意设计见 nip98.rs#L140-L163 的注释与测试 payload_tag_absent_with_body_passes。重放防护是 NIP-98 校验的结构性缺口校验本身不检查同一事件 ID 是否已用过这需要共享状态。在多中继 pod 部署下进程内缓存moka、DashMap无法跨 pod 携带新鲜度证明因此 crates/buzz-auth/src/nip98_replay.rs 定义了共享、社区作用域、原子 seen-set 的Nip98ReplayGuard特质生产实现位于buzz-pubsubRedisSET NX EX键格式buzz:{community}:nip98:{event_id_hex}社区前缀是重放层的 S1 隔离围栏——同 ID 跨社区重放必须查询两条独立 seen-set 行见 nip98_replay_keyTTL 约束DEFAULT_REPLAY_TTL_SECS 120下限须覆盖 ±60s 时钟偏移的 2 倍窗口MAX_REPLAY_TTL_SECS 3600上限防止超长 seen-set 条目与 RedisEX解析失败先校验、后标记顺序若对伪造事件先烧掉 seen-set 槽位攻击者可用已知的未来事件 ID 对受害者发起 DoS见 nip98_replay.rs#L16-L27 的用法示例失败必须 fail-closedRedis 不可达时调用方必须拒绝请求而非放行——seen-set 是正确性围栏降级为出错即放行等于放弃新鲜度证明。四、授权频道成员身份是唯一闸门SECURITY.md 明确写道频道成员身份是唯一的访问控制机制没有独立的 ACL 列表或能力分类体系。成员人类或 Agent可读写所属频道非成员即使已认证请求也会被拒绝私有频道对非成员完全不可见——不出现在频道列表中订阅过滤器对私有频道事件返回空。在源码层面crates/buzz-auth/src/access.rs 定义了ChannelAccessChecker特质由数据库层buzz-db在生产环境实现buzz-auth只依赖该特质即可执行访问规则。核心函数require_scope校验作用域是否包含所需权限否则返回InsufficientScopecheck_read_access作用域 成员资格双检查失败返回ChannelAccessDeniedcheck_write_access同上对应写路径。该层有一处重要的多租户防御每个方法都接收TenantContext。冻结 schema 中channels表的主键是(community_id, id)同一 UUID 可以合法存在于两个社区——若实现者写裸WHERE id $1就会成为跨社区存在性预言机甚至可能对绑定社区 A 的请求返回社区 B 的成员资格。因此实现必须按ctx.community()限定每次查询S1 跨社区围栏。测试 access_does_not_cross_communities 用同一 pubkey、同一频道 UUID、两个社区的组合验证了授权绝不跨社区泄漏。五、追加式审计日志SHA-256 哈希链5.1 设计定位可防篡改tamper-evident而非抗篡改tamper-resistant所有事件写入buzz-audit的追加式审计日志每条记录通过 SHA-256 哈希链与前一条相连。由于链是无密钥keyless的它能检测意外损坏或单行篡改但不能抵抗拥有数据库写权限的攻击者——攻击者修改后可以重算整条链。SECURITY.md 明确指出该设计面向 SOX 级合规与 eDiscovery 场景。5.2 哈希计算确定性与租户绑定compute_hash 的字段顺序是固定的——改动它会失效所有现存链。关键设计点community_id首先参与哈希让链身份携带租户一条记录无法被从 A 社区的链中取出、再在 B 社区重新验证通过测试 community_id_is_part_of_identity 验证了这一点cross_community_row_does_not_verify 进一步用伪造行场景证明了跨链重放会被HashMismatch拒绝时间戳先归一化再哈希Postgres 的TIMESTAMPTZ只保留微秒精度而 chrono 序列化的 RFC3339 子秒位数随值变化0/3/6/9 位。若直接哈希纳秒时间戳落库后从行内重算永远无法复现原摘要。因此to_storage_precision统一截断到 6 位小数且归一化是幂等的测试 compute_hash_normalizes_sub_microsecond_timestamps 锁死此不变量detail使用 canonical JSON 序列化键排序保证跨机器、跨 Rust 版本的摘要稳定序列化失败是硬错误而非静默哈希为空presence tagSome(empty)与None用 0/1 字节区分防止哈希碰撞测试 presence_tag_distinguishes_none_from_empty。5.3 链的写入与验证AuditService 底层是 Postgres但每条链按(community_id, seq)独立维护每社区独立链log先取pg_advisory_lock(hashtextextended(...))按社区 UUID 加锁同一社区的写入被串行化以保证链一致不同社区互不阻塞、并行推进AUDIT_LOCK_NAMESPACE buzz_audit:。锁在事务提交或任何错误路径上释放catch_unwind保证 panic 也先释放锁再归还连接头节点查询log_inner读取该社区链头(seq, hash)新条目seq prev_seq 1prev_hash指向链头哈希社区首条记录prev_hash NULL、seq 1测试 community_chain_starts_at_seq_1_with_null_prev链验证verify_chain(community, from_seq, to_seq)逐条重算哈希并核对prev_hash连续性任何不一致返回ChainViolation或HashMismatch并附上序列号get_entries严格限定在单社区内读取杜绝跨社区泄漏测试 chains_are_independent_per_community 用交错写入验证了互不链接篡改检测实测测试 verify_detects_tampering_within_a_community 直接对存储行UPDATE audit_log SET actor_pubkey ...随后verify_chain精确报告HashMismatch { seq: e2.seq }。六、桌面端密钥存储OS 密钥库与安全迁移6.1 存储分层Buzz 桌面应用将 nsec 私钥存入操作系统密钥库而非明文文件macOS Keychain、Windows Credential Manager、Linux Secret Servicegnome-keyring/kwallet经 D-Bus。覆盖范围包括人类身份密钥与每个受管 Agent 密钥。从 desktop/src-tauri/Cargo.toml 可看到实现的落地方式默认 featuresystem-keyring [dep:keyring]启用keyringcratev3.6.3各平台分别启用sync-secret-serviceLinux、apple-nativemacOS、windows-nativeWindows禁用该 feature 时降级为0o600权限的私有文件。存储优先级官方策略明确BUZZ_PRIVATE_KEY环境变量——一旦设置始终优先于两种存储这是受管 Agent 与 CI 接收身份的方式OS 密钥库0o600属主私有文件——仅当无任何密钥库后端可用例如无 Secret Service 的无头 Linux时兜底。6.2 升级迁移先验证、后删除首次启动升级后时已有明文密钥迁移进密钥库顺序严格为导入密钥到密钥库读回验证往返round-trip一致性只有验证通过后才删除明文文件。关键不变量是迁移仅在密钥库可达时运行。若本次会话密钥库后端不可用应用继续从明文文件读取且不迁移——这样一次短暂的故障不会让被轮换的密钥从残留文件中复活。这是防止旧密钥残留被重新启用的精细设计。七、输入校验与 SSRF 防护的源码落地SECURITY.md 列出的输入校验清单在仓库中均有对应实现策略源码依据所有 UUID频道 ID、工作流 ID在 API 边界校验后才用于数据库查询buzz-db类型化CommunityId作为溯源围栏provenance fence在 DB 边界解引用工作流call_webhook动作 SSRF 防护目标 URL 解析后对私网/回环地址段做封禁检查crates/buzz-workflow/src/executor.rs#L838-L867 的check_ssrf工作流响应体限长防内存耗尽WEBHOOK_MAX_RESPONSE_BYTES 1024 * 10241 MiB见 executor.rs#L869-L871evalexpr条件求值沙箱化且限时executor.rs#L350-L398传递给外部 URL 的查询参数百分号编码防注入buzz-workflow请求构造路径7.1 SSRF 防护的完整攻击面覆盖call_webhook_implexecutor.rs#L874展示了教科书级的 SSRF 防护组合先解析、后解析 IP从 URL 提取 host 与端口默认 443/80在spawn_blocking线程上用系统解析器做 DNS 解析逐地址封禁判断任一解析结果命中buzz_core::network::is_private_ip即拒绝并记录SSRF blockedDNS 固定resolve pinning防 TOCTOU校验通过的 IP 通过Client::builder().resolve(host, ...)钉死在 HTTP 客户端上且每次请求新建 Client禁用连接池——否则 reqwest 自行解析可能返回与已校验地址不同的结果DNS rebinding 时间差攻击禁用系统代理与重定向代理会自行解析原主机名绕过已固定地址重定向到内网主机同样绕过检查故redirect(Policy::none())。底层的 is_not_global_unicast 是枚举式拒绝判定封禁类来自 IANA IPv4/IPv6 特殊用途地址注册表Globally Reachable列为 False/None/absent 的网段加组播空间在整体封禁信封内为显式全局可达条目如 2001::/23 内的 PCP/TURN/DNS-SD anycast保留例外。IPv4 映射::ffff:0:0:0/96、IPv4 兼容::/96与 NAT64 知名前缀64:ff9b::/96内嵌的 IPv4 地址会被递归套用 IPv4 表——IPv6 包装层的 globalTrue 并不能绕过内嵌地址检查测试见 nat64_well_known_v6 与 ipv4_mapped_v6。该判定同时被buzz-auth的 JWKS 边界、buzz-workflow的 webhook 检查与桌面端link_preview的 SSRF 检查复用见 network.rs#L46-L49 的调用方注释。7.2 evalexpr 沙箱的双重限界evalexpr并不针对对抗性输入设计——深层嵌套或递归表达式可能无限自旋。Buzz 的防护是双层限界executor.rs#L350-L398表达式长度上限 4096 字节防止最坏 O(2^n) 求值路径——因为spawn_blocking线程无法被tokio::time::timeout取消即使超时也会跑完长度限制是必要的补充100ms 硬超时求值包在tokio::time::timeout中超时返回ConditionError。八、传输安全与依赖供应链治理8.1 TLS 策略终止于边界所有生产部署应在中继或其前置反向代理处终止 TLS。中继自身不强制 TLS——这是刻意设计允许灵活部署在负载均衡器与 Ingress 控制器之后。buzz-relay进程内通过 rustls 建立出站 TLS 连接如rediss://连 ElastiCache、wss://、S3 over TLS在 crates/buzz-relay/src/main.rs#L119-L135 启动时安装 ring CryptoProvider因为 aws-lc-rs 与 ring 均被传递引入rustls 无法自行选定默认 provider。部署上TLS 姿态wss 与 ws会影响 NIP-98 期望 URL 与邀请链接的构造见 crates/buzz-relay/src/api/bridge.rs#L240 与 invites.rs#L326 的注释。8.2 依赖与代码级治理cargo audit在 CI 中扫描依赖已知漏洞#![deny(unsafe_code)]覆盖所有 crate——零 unsafe Rust。可在 crates/buzz-auth/src/lib.rs#L1 等处看到该属性的实际应用。对贡献者与维护者而言这两项意味着任何新依赖合入前都要过审计扫描任何新代码都不允许引入unsafe块。九、给部署者与集成方的实践清单结合全文将 SECURITY.md 策略落地为可操作的检查项上报渠道发现漏洞走私密 advisory 或buzzblock.xyz勿发公开 issue版本策略pre-1.0 阶段紧跟main不依赖历史版本补丁认证完整性WebSocket 写入前必须完成 NIP-42 挑战-响应REST 端点必须校验 NIP-98 签名并在多 pod 部署下启用共享Redis重放防护TTL 落在 120s3600s 区间校验失败一律 fail-closed授权正确性所有访问检查必须带TenantContext按社区限定查询勿写裸WHERE id$1私有频道对非成员不可见审计可验证性定期用verify_chain抽查哈希链注意社区链独立、首条prev_hashNULL、seq从 1 开始密钥存储桌面端确保密钥库后端可用以完成迁移无头环境依赖0o600文件CI/受管 Agent 用BUZZ_PRIVATE_KEY注入身份工作流安全webhook 目标经 SSRF 检查DNS 固定、禁代理、禁重定向条件表达式限长限时响应体控制在 1 MiB 内传输与依赖TLS 由中继/反代边界终止保持cargo audit绿色不引入unsafe代码。十、延伸阅读安全策略原文SECURITY.md认证与授权实现crates/buzz-auth/src/lib.rs、nip42.rs、nip98.rs、nip98_replay.rs、access.rs审计链实现与测试crates/buzz-audit/src/hash.rs、crates/buzz-audit/src/service.rsSSRF 判定与工作流防护crates/buzz-core/src/network.rs、crates/buzz-workflow/src/executor.rs桌面密钥库依赖配置desktop/src-tauri/Cargo.toml【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考