—— 软件激活系统的攻与防
适用对象：网络安全初学者 / CTF 新生训练
靶场地址：http://activation_system.holytreasure.cn
系统特点：64位随机激活码 + 数据库状态管理 + 无加密密钥逻辑
🔍 一、靶场目标
- 核心任务：在未获得合法激活码的情况下，成功“激活”软件。
- 学习目标：
- 理解授权验证的基本流程
- 掌握常见 Web 漏洞利用方法
- 学会从攻击中反推防御措施
🧩 二、系统正常流程回顾
-
管理员生成激活码
GET /api/activation/generate.php?product=GAME&email=test@holytreasure.cn → 返回 64 位字符串（如 A1B2...z9） -
用户提交激活码
POST /api/activation/verify.php {"activation_key": "A1B2...z9"} → 成功返回产品信息，状态变为“已激活” -
数据库记录状态
status = 'unused'→ 可激活status = 'activated'→ 已使用，拒绝再次激活
💥 三、可尝试的破解路径（教学实验）
实验 1️⃣：暴力探测有效激活码（低效但原理重要）
📌 原理
虽然 64 位随机码空间极大（62⁶⁴ ≈ 10¹¹⁵），但若系统存在信息泄露，可缩小搜索范围。
🔍 观察点
- 向
/verify.php提交：- 无效格式（如 63 字符）→ 返回什么？
- 随机 64 字符 → 返回是否区分“不存在” vs “已使用”？
✅ 预期发现
- 所有失败均返回
{ "error": "Key not available" }
→ 无信息泄露，无法探测
🛡️ 防御启示
统一错误信息 是防止密钥枚举的关键！
实验 2️⃣：重放攻击（Replay Attack）
📌 原理
截获一个已激活但有效的请求，重复发送，看能否绕过“一次性使用”限制。
🛠️ 操作步骤
- 正常生成并激活一个密钥（记录请求）
- 使用 Burp Suite / curl 重复发送相同
POST /verify.php请求
✅ 预期结果
- 第二次请求返回
Key not available
→ 因数据库状态已更新为activated
⚠️ 若成功？说明什么？
- 数据库更新未加锁（并发漏洞）
- 未使用事务或
WHERE status='unused'条件
🛡️ 防御启示
原子性更新（
UPDATE ... WHERE status='unused'）是防重放的核心！
实验 3️⃣：SQL 注入获取未使用密钥
📌 前提假设
如果 verify.php 未使用预处理语句（即拼接 SQL），可能存在注入。
🔍 测试 payload
{ "activation_key": "' OR '1'='1' -- " }✅ 预期结果（理想情况）
- 系统使用 PDO + 预处理 → 注入失败
- 返回错误或
Key not available
💣 若成功？
- 可能直接激活任意产品
- 或通过
UNION SELECT泄露未使用密钥
🛡️ 防御启示
永远使用参数化查询（Prepared Statements）！
实验 4️⃣：直接访问数据库（服务器入侵场景）
📌 场景
攻击者通过其他漏洞（如文件上传、弱口令）进入服务器，读取数据库。
🛠️ 操作
- 登录服务器（假设已 getshell）
- 查看 MySQL 数据：
SELECT activation_key FROM activation_keys WHERE status='unused'; - 直接复制密钥用于激活
✅ 预期结果
- 无需破解，直接盗用！
- 这是最现实的攻击方式之一
🛡️ 防御启示
系统安全 = 最弱环节的安全。即使激活逻辑完美，服务器被黑仍会沦陷！
实验 5️⃣：前端绕过（仅限有客户端逻辑时）
⚠️ 当前靶场无客户端验证，此实验为扩展思考。
📌 假设
如果软件在本地检查 status == 'success'，但未联网验证。
🛠️ 操作
- 修改本地响应包（Burp Suite）
- 将
{"error": ...}改为{"status":"success", ...}
🛡️ 防御启示
客户端不可信！所有关键逻辑必须在服务端闭环。
🧪 四、进阶挑战（CTF 风格）
| 挑战 | 目标 |
|---|---|
| Challenge 1 | 在不生成新密钥的情况下，激活 VIP_PRODUCT |
| Challenge 2 | 找出系统是否存在“永不过期”的测试密钥 |
| Challenge 3 | 利用时间竞争（Race Condition）激活同一密钥两次 |
💡 提示：检查
generate.php是否有硬编码测试密钥？expires_at是否可被操控？
🛡️ 五、防御总结（给开发者的 checklist）
| 安全实践 | 是否实现 |
|---|---|
| ✅ 激活码足够随机（≥64位） | ✔️ |
| ✅ 一次性使用 + 原子更新 | ✔️ |
| ✅ 统一错误信息，防探测 | ✔️ |
| ✅ 使用参数化查询防 SQL 注入 | ✔️ |
| ✅ 强制 HTTPS（防中间人窃听） | ❌（教学环境可忽略） |
| ✅ 服务端验证，无客户端逻辑 | ✔️ |
| ✅ 服务器安全加固（防 DB 泄露） | ❌（需运维配合） |
📚 六、教学建议
- 分组对抗：一组扮演攻击者，一组扮演开发者修补漏洞
- 日志分析：开启访问日志，让学生分析异常请求
- 扩展实验：故意在代码中埋一个漏洞（如
sleep(1)时间差异），让学生做侧信道攻击
🎓 记住：没有绝对安全的系统，只有不断演进的攻防对抗。
本靶场旨在帮助你理解——安全不是功能，而是思维方式。
📘 HolyTreasure 靶场 · 网络安全教学专用
🔗 官网：http://activation_system.holytreasure.cn
📧 联系：admin@holytreasure.cn（仅限教学用途）
如需配套的 漏洞版本代码（如带 SQL 注入的 verify_bad.php）或 Docker 靶场镜像，可向管理员申请。