🛡️ 狗凯源码库 · 安全审计
合同生成管理系统
审计报告与部署教程
一套轻量级的合同/单据在线生成与归档系统：JSON 文件存储、免数据库、支持合同模板配置、甲方单位库、送货地点库、归档统计与 15 天操作日志。功能完整但安全问题典型——源码里硬编码了真实姓名的默认管理员账号，且附带了一份含 29 个真实姓名的用户数据。本报告逐项拆解并给出宝塔部署教程。
技术栈：PHP + JSON 文件存储规模：16 文件⚠️ 发现敏感个人信息审计：2026-09-25
1系统全貌
免数据库的小型业务系统
核心功能
登录认证 → 合同在线生成（模板变量填充）→ 保存归档 → 统计报表 → 用户管理 → 操作日志（15 天自动清理 cleanupOldLogs()）→ 个人改密（mmxg.php）
存储设计
全部 JSON 文件：users.json（账号）、operation_logs.json（日志）、contract_template.json（合同模板）、party_companies.json（甲方库）、delivery_locations.json（送货地点）、menu_items.json（菜单）
安全设计
密码 bcrypt 哈希存储、session 登录态、日志过期清理——设计意识有，但存储方案带来天然风险（见下）
素材图
sucai/ 三张图为首页轮播的业务介绍图（全国发货/便捷操作），属功能内容非广告，已保留
02重点发现
这套源码最大的问题不在功能，在数据
🚨
发现一：硬编码默认管理员（真实姓名+明文密码）。index.php 初始化逻辑中写死了默认账号 宋佳乐 / woshengri0.0（bcrypt 存储于 users.json）。源码随包流通等于把一套真实账号密码公之于众——任何拿到源码的人都可以在同名部署中直接登录。
🚨
发现二：users.json 含 29 个真实姓名账号。包括宋佳乐、张天宇、裴鹤、吴炎杰、袁昌胜等 29 个用户（均 bcrypt 哈希）。这些极可能是某次真实使用遗留的数据，属于个人信息泄露。按教学要求测试数据保留，但再次强调：此类数据不得用于任何真实用途，涉及《个人信息保护法》。
风险说明等级JSON 文件可直接下载不配置访问控制时，浏览器直接访问 /users.json 即可下载全部账号哈希——这是 JSON 存储类源码的头号通病，部署后必须立即封禁高默认凭据硬编码账号须在初始化后第一时间改密（mmxg.php）或删除高并发写入多用户同时保存可能互相覆盖 JSON 文件（无文件锁），仅适合小团队低并发场景中日志含业务数据operation_logs.json 记录合同内容摘要，同样需封禁直接访问中
03宝塔部署教程
免数据库，重点在安全加固
1
环境准备
宝塔安装 Nginx + PHP 7.4/8.0，开启 json、session（默认即有）。无需任何数据库。
2
上传源码
整包上传到站点根目录（如 /www/wwwroot/contract.demo），全目录 755 保证 JSON 文件可写。
3
封禁 JSON 直接访问（关键步骤）
宝塔 → 站点 → 配置文件，在 server 段加入：
location ~* .json$ {
deny all;
return 404;}
保存并重载 Nginx。用浏览器访问 http://你的域名/users.json 确认返回 404——这一步不做，等于把账号库挂在网上。
4
首次登录与整改
访问首页登录（演示可直接用测试数据中的账号体系熟悉流程），随后立即做两件事：① 用 mmxg.php 修改默认账号密码；② 后台用户管理删除不需要的遗留账号，或直接清空 users.json 仅保留一个自己的管理员（首次访问会自动重新初始化）。
5
配置业务数据
合同模板、甲方单位库、送货地点、菜单均可直接编辑对应 JSON 文件，或通过后台界面维护（admin.php）。sucai/ 轮播图可替换为自己的介绍图。
6
验证
登录 → 生成一份合同 → 归档 → 统计页查看报表；
确认 operation_logs.json 正常记录且 15 天自动清理生效；
改密接口走一遍旧密码验证 → 新密码生效。
🎓
教学价值：这是学习「JSON 文件型存储的安全边界」的典型样本：文件锁缺失、Web 可下载、敏感数据混入源码包——三个问题都在这套小系统里齐了。部署演示时对照本报告第 02 节逐项加固，比看十篇理论文章都直观。
