AssppWeb安全模型分析：主机名白名单、账户哈希与浏览器安全边界的设计哲学

AssppWeb安全模型分析主机名白名单、账户哈希与浏览器安全边界的设计哲学【免费下载链接】AssppWeb项目地址: https://gitcode.com/gh_mirrors/as/AssppWebAssppWeb 是一款基于 Web 的 iOS 应用获取与安装工具让你无需 Mac 电脑直接用浏览器登录 Apple ID、搜索应用并安装 IPA 到 iPhone。它采用零信任架构服务器永远接触不到你的 Apple 凭据所有与 Apple 服务器的通信都在浏览器内通过 WebAssembly 完成后端只是一个盲传的 TCP 中继。本文将从主机名白名单、账户哈希与浏览器安全边界三个维度剖析这套安全模型背后的设计哲学。一、零信任架构服务器为什么看不见你的账户传统 Web 应用的常规做法是把 Apple ID 和密码提交给后端由后端代为登录、购买、下载。这要求用户完全信任服务器运营者——而 AssppWeb 选择了一条更极端的路服务器从头到尾只看到加密后的流量字节流看不到任何明文凭据。它的核心机制是浏览器端通过 WebAssemblylibcurl.js 配合 Mbed TLS 1.3直接与 Apple 服务器建立加密连接后端运行一个名为 Wisp 的 TCP 中继服务只负责转发字节不解密、不解析IPA 编译与缓存由服务器从公开 CDN 下载后完成这部分数据本身不含任何凭据。⚠️ 官方提醒不存在官方 AssppWeb 公共实例。恶意托管者虽然读不懂你的加密流量却可能替换前端页面来窃取凭据。因此强烈建议自建实例并始终核验 SSL 证书。这个设计的哲学是把信任从架构中移除而不是靠代码注释承诺我们不会看你的密码。二、主机名白名单TCP 中继的单一出口闸门盲传中继最大的风险是如果中继不限制目标地址恶意前端可以借道你的服务器发起任意 TCP 连接扫描内网、连接任意第三方服务器。AssppWeb 在 backend/src/services/wsProxy.ts 中用一组白名单把风险锁死主机名白名单——只允许 5 类 Apple 官方域名auth.itunes.apple.com、buy.itunes.apple.com、init.itunes.apple.com、p*-buy.itunes.apple.com各地区商店节点、downloaddispatch.itunes.apple.com端口白名单——只放行 443即强制 HTTPS禁止直连 IPallow_direct_ip false——杜绝绕过域名校验直接打 IP禁止回环地址——中继无法被用来探测服务器本机服务。一个值得注意的细节是allow_private_ips true。源码注释解释了原因Docker/容器环境中的 DNS 可能把白名单域名解析为保留网段 IP如 OrbStack 的 198.18.x.x因此安全控制的重心放在主机名匹配上而非 IP 段。这是白名单锚定在域名语义上的典型取舍。三、账户哈希服务器只知道谁来了不知道是谁当你发起下载任务时服务器需要区分任务属于哪个账户但 AssppWeb 不传递 Apple ID 或邮箱明文。frontend/src/utils/account.ts 中的accountHash函数会对账户标识directoryServicesIdentifier缺失时回退到appleId或email计算SHA-256 哈希只有这串十六进制摘要会随 DownloadTask 和 PackageInfo 传到后端。这套设计带来三个好处最小暴露面服务器存储与日志中永远只有哈希值无法反推出真实邮箱不可逆性SHA-256 是单向函数拿到哈希也无法还原账户身份降级容错若环境不支持crypto.subtle还会退回到 FNV-1a 64 位哈希保证功能可用。对比账号哈希IPA 包缓存、下载进度、manifest 生成等服务端功能完全不受影响——身份被匿名化但业务照常运转。四、浏览器安全边界Apple ID 凭据究竟存在哪里在 AssppWeb 中你的 Apple ID、会话 Cookie、passwordToken等敏感数据见 Account 类型定义只存放在浏览器的 IndexedDB 里对应 frontend/src/store/accounts.ts 中的asspp-accounts数据库。更关键的是落盘前会经过完整加密由访问密码经PBKDF2SHA-25610 万次迭代派生出 AES 密钥用AES-GCM-256加密每次随机生成 16 字节盐与 12 字节 IV最终格式为salt IV 密文的 Base64 串见 frontend/src/utils/crypto.ts。同时与 Apple 服务器会话的 Cookie 处理也有讲究frontend/src/apple/cookies.ts 严格校验 Cookie 的域名、路径、有效期与 Secure 标志SecureCookie 只会在 HTTPS 下发送。凭据的生命周期被完全圈定在浏览器这个安全边界之内服务器端连数据库里都没有一张用户表。五、访问密码公共实例的最后一道门零信任解决的是服务器不能看但如果实例本身被人共享使用呢AssppWeb 提供可选的ACCESS_PASSWORD环境变量见 compose.yml 中的环境变量表设置了密码后Web 界面与 API 需要先通过 PasswordGate 获取访问令牌backend/src/middleware/accessAuth.ts 会校验每个请求的x-access-tokenWebSocket 中继/wisp/端点同样要求令牌wsProxy.ts且只放行/auth/与/install/路径的免检访问。密码在服务器侧以哈希形式存储accessPasswordHash配合反向代理的 TLS 终结与 CDN 防护构成自托管场景下的纵深防御。六、小结把信任当作成本来花AssppWeb 的安全模型可以浓缩为三条原则机制位置效果主机名 端口白名单后端 Wisp 中继盲传通道只通向 Apple 官方域名账户 SHA-256 哈希前端生成、后端消费服务器无法还原用户身份凭据浏览器内加密存储IndexedDB AES-GCM密钥与凭据从不离开客户端它的哲学不是我保证不滥用你的数据而是让架构本身使滥用变得不可能——这正值得每一个处理用户敏感信息的开源项目参考。【免费下载链接】AssppWeb项目地址: https://gitcode.com/gh_mirrors/as/AssppWeb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考