企业官网建设流程全解析

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

【免费下载链接】AssppWeb项目地址: https://gitcode.com/gh_mirrors/as/AssppWeb

AssppWeb 是一款基于 Web 的 iOS 应用获取与安装工具，让你无需 Mac 电脑，直接用浏览器登录 Apple ID、搜索应用并安装 IPA 到 iPhone。它采用零信任架构：服务器永远接触不到你的 Apple 凭据，所有与 Apple 服务器的通信都在浏览器内通过 WebAssembly 完成，后端只是一个"盲传"的 TCP 中继。本文将从主机名白名单、账户哈希与浏览器安全边界三个维度，剖析这套安全模型背后的设计哲学。

一、零信任架构：服务器为什么"看不见"你的账户

传统 Web 应用的常规做法是：把 Apple ID 和密码提交给后端，由后端代为登录、购买、下载。这要求用户完全信任服务器运营者——而 AssppWeb 选择了一条更极端的路：服务器从头到尾只看到加密后的流量字节流，看不到任何明文凭据。

它的核心机制是：

• 浏览器端通过 WebAssembly（libcurl.js 配合 Mbed TLS 1.3）直接与 Apple 服务器建立加密连接；
• 后端运行一个名为 Wisp 的 TCP 中继服务，只负责"转发字节"，不解密、不解析；
• IPA 编译与缓存由服务器从公开 CDN 下载后完成，这部分数据本身不含任何凭据。

⚠️ 官方提醒：不存在"官方 AssppWeb 公共实例"。恶意托管者虽然读不懂你的加密流量，却可能替换前端页面来窃取凭据。因此强烈建议自建实例，并始终核验 SSL 证书。

这个设计的哲学是：把"信任"从架构中移除，而不是靠代码注释承诺"我们不会看你的密码"。

二、主机名白名单：TCP 中继的单一出口闸门

盲传中继最大的风险是：如果中继不限制目标地址，恶意前端可以借道你的服务器发起任意 TCP 连接（扫描内网、连接任意第三方服务器）。AssppWeb 在 backend/src/services/wsProxy.ts 中用一组白名单把风险锁死：

1. 主机名白名单——只允许 5 类 Apple 官方域名：auth.itunes.apple.com、buy.itunes.apple.com、init.itunes.apple.com、p*-buy.itunes.apple.com（各地区商店节点）、downloaddispatch.itunes.apple.com；
2. 端口白名单——只放行 443，即强制 HTTPS；
3. 禁止直连 IP（allow_direct_ip = false）——杜绝绕过域名校验直接打 IP；
4. 禁止回环地址——中继无法被用来探测服务器本机服务。

一个值得注意的细节是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数据库。更关键的是，落盘前会经过完整加密：

• 由访问密码经PBKDF2（SHA-256，10 万次迭代）派生出 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-token；
• WebSocket 中继/wisp/端点同样要求令牌（wsProxy.ts），且只放行/auth/与/install/路径的免检访问。

密码在服务器侧以哈希形式存储（accessPasswordHash），配合反向代理的 TLS 终结与 CDN 防护，构成自托管场景下的纵深防御。

六、小结：把"信任"当作成本来花

AssppWeb 的安全模型可以浓缩为三条原则：

它的哲学不是"我保证不滥用你的数据"，而是让架构本身使滥用变得不可能——这正值得每一个处理用户敏感信息的开源项目参考。

【免费下载链接】AssppWeb项目地址: https://gitcode.com/gh_mirrors/as/AssppWeb