从二维码登录到安全收尾：一个轻量文件柜系统的设计、审计与加固实践
本文中的项目名称、域名、主机名、账号、目录、Cookie 名称、时间参数、容量限制和命令均为虚构示例，仅用于说明技术方案，不对应任何真实部署环境。 一、项目目标 在家庭服务器或小型内部网络中，经常需要一种比网盘更轻量的文件交换工具： 基于这些需求，设计了一个名为 LanternBox 的示例系统。 它采用 PHP、SQLite 和现有 Web 服务器运行，不新增独立公网端口，不依赖常驻应用服务，也不把用户文件映射成静态下载地址。 整体结构如下： 二维码只负责临时授权。真正的用户身份由已经登记的手机浏览器持有，电脑获得的则是短期会话。 二、示例部署结构 示例环境使用以下虚构信息： 项目目录大致划分为： 这里最重要的设计不是“禁止访问几个敏感目录”，而是： 默认拒绝整个项目，只显式开放 public/。 示例 Apache 配置如下： 这种配置的安全意义是： 安全审计中，公开入口可以正常访问，而核心代码、配置、数据库和工具路径均未发现可用的公网绕过方式；普通用户访问管理入口也会被拒绝。 三、认证设计：手机浏览器作为可信设备 3.1 为什么不使用密码 对于少量家庭成员或内部使用者，账号密码会引入额外负担： 因此，系统采用手机设备登记与二维码批准模式。 3.2 首次登记流程 管理员创建用户后，为该用户生成一次性登记链接，例如： 手机浏览器打开链接后，服务器执行以下操作： 示例 Cookie： 登记令牌必须具备一次性和短时效特征。审计验证表明，一次性登记、令牌到期、使用后清除以及安全 Cookie 属性都能够正常工作。 3.3 电脑端扫码登录 电脑打开登录页后，服务器生成一条短期登录请求。 页面显示二维码，二维码中不直接包含永久设备凭据，而是一个短时、一次性的批准入口。 流程如下： 为了防止登录劫持，系统必须保证： 四、同一浏览器只能绑定一个账号的问题 在实际测试中发现，一个浏览器配置文件先登记管理员，再登记普通用户后，管理员身份会被普通用户覆盖。 原因并不是浏览器只能保存一个 Cookie，而是相同的： 只能对应一个当前值。 …