{
"id": "web2",
"name": "Web2 安全",
"icon": "globe",
"description": "Web 应用安全漏洞题目，包括 SQL 注入、XSS、SSRF、文件上传等常见漏洞",
"enabled": true,
"sort_order": 1,
"form_fields": [
{
"help_text": "选择题目使用的后端语言",
"hidden": false,
"icon": "code",
"id": "language",
"label": "语言",
"options": [
{
"icon": "fab fa-python",
"label": "Python",
"value": "Python"
},
{
"icon": "fab fa-php",
"label": "PHP",
"value": "PHP"
},
{
"icon": "fab fa-node-js",
"label": "Node.js",
"value": "Node.js"
},
{
"icon": "fab fa-java",
"label": "Java",
"value": "Java"
},
{
"icon": "fas fa-code",
"label": "Go",
"value": "Go"
},
{
"icon": "fas fa-code",
"label": "C/C++",
"value": "C/C++"
}
],
"order": 1,
"required": true,
"type": "select",
"visible": true
},
{
"depends_on": {
"condition": "not_empty",
"field": "language"
},
"icon": "signal",
"id": "difficulty",
"label": "难度级别",
"options": [
{
"description": "最多1个漏洞，适合新手",
"icon": "seedling",
"label": "入门",
"value": "入门"
},
{
"description": "最多2个漏洞",
"icon": "leaf",
"label": "简单",
"value": "简单"
},
{
"description": "最多3个漏洞，需要一定经验",
"icon": "tree",
"label": "中等",
"value": "中等"
},
{
"description": "最多5个漏洞，需要较强能力",
"icon": "mountain",
"label": "困难",
"value": "困难"
}
],
"order": 2,
"readonly": true,
"required": true,
"type": "select",
"visible": true
},
{
"depends_on": {
"condition": "not_empty",
"field": "difficulty"
},
"icon": "bug",
"id": "vulnerability",
"label": "漏洞类型",
"max_count_rules": {
"mapping": {
"中等": 3,
"入门": 1,
"困难": 5,
"简单": 2
},
"source": "difficulty"
},
"options": [
{
"category": "API安全",
"items": [
{
"label": "GraphQL安全",
"value": "GraphQL安全"
},
{
"label": "REST API滥用",
"value": "REST API滥用"
}
]
},
{
"category": "HTTP协议",
"items": [
{
"label": "HTTP参数污染",
"value": "HTTP参数污染"
},
{
"label": "HTTP请求走私",
"value": "HTTP请求走私"
},
{
"label": "开放重定向",
"value": "开放重定向"
},
{
"label": "缓存投毒",
"value": "缓存投毒"
}
]
},
{
"category": "Node.js特性",
"items": [
{
"label": "Node.js沙箱逃逸",
"value": "Node.js沙箱逃逸"
}
]
},
{
"category": "PHP特性",
"items": [
{
"label": "PHP Session漏洞",
"value": "PHP Session漏洞"
},
{
"label": "PHP disable_functions绕过",
"value": "PHP disable_functions绕过"
},
{
"label": "PHP伪协议",
"value": "PHP伪协议"
},
{
"label": "PHP变量覆盖",
"value": "PHP变量覆盖"
},
{
"label": "PHP弱类型函数",
"value": "PHP弱类型函数"
},
{
"label": "PHP类型杂耍",
"value": "PHP类型杂耍"
}
]
},
{
"category": "Python特性",
"items": [
{
"label": "Python格式化字符串",
"value": "Python格式化字符串"
},
{
"label": "Python沙箱逃逸",
"value": "Python沙箱逃逸"
}
]
},
{
"category": "业务逻辑",
"items": [
{
"label": "业务逻辑缺陷",
"value": "业务逻辑缺陷"
},
{
"label": "竞态条件",
"value": "竞态条件"
},
{
"label": "类型混淆",
"value": "类型混淆"
}
]
},
{
"category": "信息泄露",
"items": [
{
"label": "敏感信息泄露",
"value": "敏感信息泄露"
},
{
"label": "源码泄露",
"value": "源码泄露"
}
]
},
{
"category": "其他",
"items": [
{
"label": "整数溢出",
"value": "整数溢出"
}
]
},
{
"category": "前端安全",
"items": [
{
"label": "CORS配置错误",
"value": "CORS配置错误"
},
{
"label": "CSP绕过",
"value": "CSP绕过"
},
{
"label": "DOM Clobbering",
"value": "DOM Clobbering"
},
{
"label": "PostMessage安全",
"value": "PostMessage安全"
},
{
"label": "原型链污染",
"value": "原型链污染"
}
]
},
{
"category": "反序列化漏洞",
"items": [
{
"label": "Java反序列化",
"value": "Java反序列化"
},
{
"label": "Node.js反序列化",
"value": "Node.js反序列化"
},
{
"label": "PHP反序列化",
"value": "PHP反序列化"
},
{
"label": "Python反序列化",
"value": "Python反序列化"
}
]
},
{
"category": "密码学",
"items": [
{
"label": "Padding Oracle",
"value": "Padding Oracle"
},
{
"label": "哈希长度扩展",
"value": "哈希长度扩展"
},
{
"label": "弱加密",
"value": "弱加密"
}
]
},
{
"category": "文件操作漏洞",
"items": [
{
"label": "文件上传",
"value": "文件上传"
},
{
"label": "文件包含",
"value": "文件包含"
},
{
"label": "路径穿越",
"value": "路径穿越"
}
]
},
{
"category": "注入类漏洞",
"items": [
{
"label": "CRLF注入",
"value": "CRLF注入"
},
{
"label": "NoSQL注入",
"value": "NoSQL注入"
},
{
"label": "SQL注入",
"value": "SQL注入"
},
{
"label": "SSTI模板注入",
"value": "SSTI模板注入"
},
{
"label": "代码注入",
"value": "代码注入"
},
{
"label": "命令注入",
"value": "命令注入"
},
{
"label": "表达式注入",
"value": "表达式注入"
}
]
},
{
"category": "绕过技术",
"items": [
{
"label": "WAF绕过",
"value": "WAF绕过"
},
{
"label": "沙箱逃逸",
"value": "沙箱逃逸"
},
{
"label": "过滤绕过",
"value": "过滤绕过"
}
]
},
{
"category": "认证与授权",
"items": [
{
"label": "JWT安全",
"value": "JWT安全"
},
{
"label": "OAuth安全",
"value": "OAuth安全"
},
{
"label": "Session安全",
"value": "Session安全"
},
{
"label": "认证绕过",
"value": "认证绕过"
},
{
"label": "越权访问",
"value": "越权访问"
}
]
},
{
"category": "请求伪造",
"items": [
{
"label": "DNS重绑定",
"value": "DNS重绑定"
},
{
"label": "SSRF服务端请求伪造",
"value": "SSRF服务端请求伪造"
},
{
"label": "XXE外部实体注入",
"value": "XXE外部实体注入"
}
]
},
{
"category": "跨站攻击",
"items": [
{
"label": "CSRF跨站请求伪造",
"value": "CSRF跨站请求伪造"
},
{
"label": "XSS跨站脚本",
"value": "XSS跨站脚本"
}
]
}
],
"order": 3,
"required": true,
"type": "multi_select_categorized",
"visible": true
},
{
"depends_on": {
"condition": "count_gt_0",
"field": "vulnerability"
},
"hidden": false,
"icon": "building",
"id": "scene",
"label": "应用场景",
"options": [
{
"icon": "ban",
"label": "无场景",
"value": "none"
},
{
"icon": "university",
"label": "金融服务",
"value": "金融服务"
},
{
"icon": "university",
"label": "银行系统",
"value": "银行系统"
},
{
"icon": "university",
"label": "支付平台",
"value": "支付平台"
},
{
"icon": "university",
"label": "投资理财",
"value": "投资理财"
},
{
"icon": "university",
"label": "保险平台",
"value": "保险平台"
},
{
"icon": "building",
"label": "企业办公",
"value": "企业办公"
},
{
"icon": "building",
"label": "企业门户",
"value": "企业门户"
},
{
"icon": "building",
"label": "OA系统",
"value": "oa系统"
},
{
"icon": "building",
"label": "CRM系统",
"value": "crm系统"
},
{
"icon": "building",
"label": "人力资源",
"value": "人力资源"
},
{
"icon": "building",
"label": "招聘平台",
"value": "招聘平台"
},
{
"icon": "shopping-cart",
"label": "电子商务",
"value": "电子商务"
},
{
"icon": "shopping-cart",
"label": "网上商城",
"value": "网上商城"
},
{
"icon": "shopping-cart",
"label": "外卖平台",
"value": "外卖平台"
},
{
"icon": "shopping-cart",
"label": "二手交易",
"value": "二手交易"
},
{
"icon": "shopping-cart",
"label": "物流配送",
"value": "物流配送"
},
{
"icon": "graduation-cap",
"label": "教育培训",
"value": "教育培训"
},
{
"icon": "graduation-cap",
"label": "教务系统",
"value": "教务系统"
},
{
"icon": "graduation-cap",
"label": "在线课程",
"value": "在线课程"
},
{
"icon": "graduation-cap",
"label": "考试系统",
"value": "考试系统"
},
{
"icon": "graduation-cap",
"label": "图书馆",
"value": "图书馆"
},
{
"icon": "users",
"label": "社交媒体",
"value": "社交媒体"
},
{
"icon": "users",
"label": "社交网络",
"value": "社交网络"
},
{
"icon": "users",
"label": "博客论坛",
"value": "博客论坛"
},
{
"icon": "users",
"label": "即时通讯",
"value": "即时通讯"
},
{
"icon": "users",
"label": "短视频",
"value": "短视频"
},
{
"icon": "heartbeat",
"label": "医疗健康",
"value": "医疗健康"
},
{
"icon": "heartbeat",
"label": "挂号系统",
"value": "挂号系统"
},
{
"icon": "heartbeat",
"label": "电子病历",
"value": "电子病历"
},
{
"icon": "heartbeat",
"label": "药品管理",
"value": "药品管理"
},
{
"icon": "heartbeat",
"label": "健康咨询",
"value": "健康咨询"
},
{
"icon": "landmark",
"label": "政务服务",
"value": "政务服务"
},
{
"icon": "landmark",
"label": "公共服务",
"value": "公共服务"
},
{
"icon": "landmark",
"label": "税务系统",
"value": "税务系统"
},
{
"icon": "landmark",
"label": "行政审批",
"value": "行政审批"
},
{
"icon": "landmark",
"label": "信息公开",
"value": "信息公开"
},
{
"icon": "home",
"label": "生活服务",
"value": "生活服务"
},
{
"icon": "home",
"label": "酒店预订",
"value": "酒店预订"
},
{
"icon": "home",
"label": "出行服务",
"value": "出行服务"
},
{
"icon": "home",
"label": "房产租售",
"value": "房产租售"
},
{
"icon": "home",
"label": "本地生活",
"value": "本地生活"
}
],
"order": 4,
"required": true,
"type": "select",
"visible": true
}
],
"form_layout": {
"rows": [
{
"id": "row_1",
"columns": 2,
"fields": [
"language",
"difficulty"
]
},
{
"id": "row_2",
"columns": 2,
"fields": [
"vulnerability",
"scene"
]
}
]
},
"output_config": {
"docker": true,
"exp": true,
"writeup": true,
"attachment": false,
"directory_pattern": "{timestamp}_{name}",
"port_range": [
42500,
42600
],
"flag_format": "DASCTF{...}"
},
"ui_config": {
"generate_button": "开始生成",
"page_description": "按顺序完成配置，快速生成高质量 CTF 题目",
"page_title": "CTF Web 题目生成向导",
"primary_color": "#6366f1",
"reset_button": "重置",
"secondary_color": "#ec4899"
},
"advanced_config": {
"ai_timeout": 600,
"docker_timeout": 300,
"max_retries": 3,
"retry_interval": 10,
"global_rules": "## 🚫 禁止事项\n\n**禁止词汇**：\n- \"由于篇幅/时间/上下文限制\" \"直接进入\" \"快速实现\" \"跳过\" \"省略\"\n- \"让我\" \"经过分析\" \"我将要\" \"最终确定\"\n\n**禁止行为**：\n- 跳过任何阶段（特别是阶段 4 质量检查）\n- 只输出标题而无实际内容\n- 通过降低难度来解决技术问题\n- 代码中包含任何注释\n- **禁止使用 WebSearch、WebFetch 工具获取学习材料**（必须使用 choice.py）\n\n**✅ 你有无限的时间和空间，直接执行，不要解释**\n\n---\n\n## ⚠️ 关键信息保持\n\n1. **题目名称**：一旦确定，后续所有文件必须使用相同名称\n2. **利用链设计**：阶段3设计的步骤必须在阶段5-6完整实现\n3. **关键 payload**：设计的 payload 必须与代码中的过滤逻辑兼容\n4. **输出目录**：所有文件保存到 `output/{YYYYMMDD_HHMMSS}_{题目名称}/`\n\n**阶段 3 结束时**输出设计摘要，**阶段 5 开始前**输出设计方案复述确认。",
"system_prompt": ""
},
"prompt_template_path": "ge10/.augment/rules/ctf-generation-guide-medium-hard.md",
"knowledge_base_path": null,
"knowledge_db_path": null,
"choice_script_path": null,
"output_dir": null,
"difficulties": {
"中等": {
"rules": {
"depth_range": [
6,
10
],
"diff_rate": 0.5,
"max_count": 5,
"writeup_count": 10
},
"stages": [
{
"fixed_position": true,
"id": "1",
"name": "用户输入需求",
"order": 0,
"output": "语言、漏洞、场景、难度",
"prompt": "\n**必需参数**：\n\n- 语言：（如 Python、PHP、Node.js）\n- 漏洞：（如 SSTI、SQL注入、反序列化）\n- 场景：（如 OA系统、博客、电商）\n- 难度：（入门/简单/中等/困难）\n\n**示例**：\n\n```\n语言：Python\n漏洞：逻辑漏洞\n场景：OA系统\n难度：中等\n```\n\n**⚠️ 额外要求处理规则**：\n- 如果用户提供了额外要求，必须在题目设计时充分考虑并融入\n- 额外要求的优先级高于默认设计方案\n- 在设计阶段需要明确说明如何满足用户的额外要求\n\n**⚠️ 重要提醒**：在开始任何工作之前，请记住：\n\n- 所有生成的文件必须保存到 `output/{YYYYMMDD_HHMMSS}_{题目名称}/` 目录\n- 在代码生成开始前，必须先创建输出目录\n",
"required": true,
"system_stage": true
},
{
"condition": "knowledge_count > 1",
"id": "2",
"name": "漏洞主次分类",
"order": 1,
"output": "主漏洞/辅助漏洞分配",
"prompt": "\n**在获取学习材料之前，必须对用户选择的漏洞进行主次分类**。\n\n### 🎯 分类目的\n\n确保 AI 有足够的学习材料来深入理解核心漏洞，避免因漏洞过多导致每个漏洞的 writeup 数量不足。\n\n### 📊 分类规则\n\n根据以下标准将用户选择的漏洞分为**主漏洞**和**辅助漏洞**：\n\n**主漏洞**（1-2 个）：\n- 题目的核心考点，利用链的关键步骤\n- 通常是高深度漏洞（如 SSTI、反序列化、原型链污染、SQL注入、命令注入）\n- 需要深入理解才能利用的漏洞\n\n**辅助漏洞**（0-3 个）：\n- 用于信息收集、权限提升或辅助利用\n- 通常是中低深度漏洞（如路径穿越、文件包含、JWT安全、类型混淆、信息泄露）\n- 作为利用链的前置或后置步骤\n\n### 📝 分类输出格式\n\n```markdown\n### 漏洞主次分类\n\n**用户选择的漏洞**：SSTI模板注入、JWT安全、路径穿越\n\n**分类结果**：\n| 漏洞 | 分类 | 理由 |\n|------|------|------|\n| SSTI模板注入 | 主漏洞 | 高深度漏洞，需要理解模板引擎和沙箱绕过，适合作为核心考点 |\n| JWT安全 | 辅助漏洞 | 用于认证绕过，作为获取权限的前置步骤 |\n| 路径穿越 | 辅助漏洞 | 用于信息收集，获取配置文件或密钥 |\n\n**writeup 分配**：\n- 主漏洞（SSTI模板注入）：6 篇（60%）\n- 辅助漏洞（JWT安全）：2 篇（20%）\n- 辅助漏洞（路径穿越）：2 篇（20%）\n```\n\n### ⚠️ 特殊情况处理\n\n1. **只有 1 个漏洞**：该漏洞自动作为主漏洞，分配全部 writeup\n2. **所有漏洞都是高深度**：选择与场景最契合的作为主漏洞\n3. **所有漏洞都是辅助性质**：选择深度最高的作为主漏洞\n\n",
"required": false
},
{
"description": "根据用户输入和配置的脚本，从知识库中筛选并获取相关的知识点和 Writeup",
"id": "3",
"knowledge_script_code": "",
"knowledge_script_instruction": "",
"knowledge_script_name": "",
"knowledge_script_path": "",
"name": "知识库获取",
"order": 2,
"output_format": "json",
"prompt": "### 3.1 获取学习材料（必须使用 choice.py）\n```bash\npython3 data/scripts/choice.py --difficulty=<难度> --count=<数量> \"漏洞名称1\" \"漏洞名称2\"\n```\n\n**⚠️ 漏洞名称必须使用用户输入的完整名称，禁止简化或缩写！**\n- ✅ 正确：`\"SSTI模板注入\"` `\"SQL注入\"` `\"文件上传漏洞\"`\n- ❌ 错误：`\"SSTI\"` `\"SQL\"` `\"文件上传\"`\n\n**示例**：\n```bash\npython3 data/scripts/choice.py --difficulty=简单 --count=3 \"SQL注入\"\npython3 data/scripts/choice.py --difficulty=简单 --count=2 \"信息泄露\"\npython3 data/scripts/choice.py --difficulty=简单 --count=5 \"SSTI模板注入\" \"SQL注入\"\n```\n\n**choice.py 会输出选中的 writeup 文件名，然后使用 Read 工具读取 `data/writeups` 目录下对应的 .md 文件**\n\n\n### 🔍 1.2 深度学习与分析\n\n**随机阅读其中的10篇** writeup(若 writeup 不完整/不清晰，使用互联网搜索补充)。\n\n💡 **提示**：`choice.py` 会根据难度自动选出10篇writeup，你需要全部阅读这10篇writeup。\n\n重点关注：\n\n#### (1) 利用链拆解\n\n- 完整路径：入口 → FLAG\n- 关键节点：步骤类型、技术点\n- 依赖关系：前置条件\n- 深度评分：1-10 分\n\n#### (2) 核心知识提取\n\n**这是最重要的环节，必须深度挖掘**：\n\n##### a) 选手的困难点（题目深度的体现）\n\n- 记录 writeup 中的\"卡住的地方\"、\"尝试了很久\"、\"最后发现\"\n- 示例：\"尝试了各种 SQL 注入 payload 都失败，最后发现需要利用 JSON 函数\"\n\n##### b) 关键的灵光一现（\"啊哈时刻\"）\n\n- 需要特殊知识或经验才能想到的技巧\n- 示例：\"突然想到可以利用 XXX 特性\"、\"查阅文档后发现 XXX\"\n\n##### c) 技术深度体现\n\n- 需要理解底层原理的地方\n- 需要查阅文档或源码的地方\n- 示例：\"需要理解 PHP 序列化格式\"、\"需要分析 GD 库的处理流程\"\n\n##### d) 巧妙的设计\n\n- 误导性设计（诱饵路径）\n- 隐藏的关联性\n- 非直观的利用方式\n\n##### e) 非预期解法\n\n- 分析为什么会出现非预期\n- 学习如何防止类似问题\n\n#### (3) 技术组合模式\n\n- 组合类型：串行链/并行验证/状态机转换\n- 防护-绕过对：记录防护机制及绕过技巧\n- 创新点识别：⭐⭐⭐ 高度创新 / ⭐⭐ 中度创新 / ⭐ 常见技巧\n\n#### (4) 场景与业务逻辑\n\n- 真实场景还原度（1-10 分）\n- 误导设计技巧\n- 状态管理方式\n\n---\n\n### 📊 1.3 学习成果输出\n\n输出以下内容：\n\n```markdown\n## Writeup 分析报告 #N\n\n### 利用链拆解\n| 步骤 | 类型 | 技术点 | 输入 | 输出 | 依赖 | 深度 |\n|------|------|--------|------|------|------|------|\n| Step 1 | 信息收集 | 目录遍历 | URL | 配置文件 | 无 | 2/10 |\n| Step 2 | 防护绕过 | WAF绕过 | 配置文件 | payload | Step 1 | 5/10 |\n\n### 深度亮点分析 ⭐（最重要）\n1. **困难点**：选手卡住的地方（体现题目深度）\n2. **啊哈时刻**：需要灵光一现的技巧\n3. **技术深度**：需要理解底层原理的地方\n4. **巧妙设计**：误导路径、隐藏关联、非直观利用\n5. **非预期解**：为什么出现、如何防止\n\n### 创新点提取\n1. ⭐⭐⭐ [高度创新] xxx\n2. ⭐⭐ [中度创新] xxx\n\n### 可借鉴设计模式\n- 模式1：xxx（适用场景：xxx）\n```\n\n---\n\n### 📋 1.4 学习成果自检\n\n在进入下一阶段前，确认并输出：\n\n- [ ] 已分析至少 **80%** 的有效 writeup\n- [ ] 至少提取了 **10 个**可借鉴的设计模式\n- [ ] 至少发现了 **5 个**创新组合灵感\n- [ ] 对目标漏洞的深度理解达到 **8/10** 以上\n- [ ] 已掌握至少 **3 种**该漏洞的不同利用方式\n- [ ] 已了解至少 **5 种**防护-绕过对\n\n**若未达标 → 继续学习**\n\n---\n",
"required": true,
"system_prompt": "根据用户输入的需求，使用配置的知识库筛选脚本，从知识库中获取相关的知识点和 Writeup 文件。",
"system_stage": true,
"user_extension": ""
},
{
"id": "4",
"name": "知识模块化与映射",
"order": 3,
"output": "知识模块库、知识组合方案",
"prompt": "### 4.1 知识模块提取\n\n**从学习阶段提取可复用的知识模块**：\n\n```markdown\n## 知识模块库\n\n| 模块ID | 技术点 | 适用场景 | 前置条件 | 输出结果 | 深度 | 可组合性 | 来源 |\n|--------|--------|---------|---------|---------|------|---------|------|\n| KB-001 | 配置文件读取 | 任何Web应用 | 路径遍历 | 敏感配置 | 3/10 | 高 | WP#3 |\n| KB-002 | JWT密钥泄露利用 | 使用JWT的应用 | 已知密钥 | 伪造token | 5/10 | 中 | WP#3 |\n| KB-003 | SSTI沙箱绕过 | Python模板引擎 | SSTI触发点 | RCE | 8/10 | 中 | WP#7 |\n| KB-004 | 审批流程状态机绕过 | OA/工单系统 | 状态转换点 | 越权操作 | 7/10 | 中 | - |\n| KB-005 | 优惠券/积分逻辑漏洞 | 电商/营销系统 | 业务逻辑 | 金额篡改 | 6/10 | 高 | - |\n| ... | ... | ... | ... | ... | ... | ... | ... |\n```\n\n**要求**：\n\n- 至少提取 **15 个**独立的知识模块\n- 每个模块有清晰的\"输入-处理-输出\"定义\n- 标注深度评分和可组合性\n\n### 4.2 知识组合矩阵\n\n**识别可组合的知识模块**：\n\n```markdown\n## 知识组合方案\n\n| 组合ID | 模块1 | 模块2 | 组合方式 | 创新度 | 难度提升 | 适用场景 | 来源 |\n|--------|-------|-------|---------|--------|---------|---------|------|\n| COMB-001 | KB-001 | KB-002 | 串行 | ⭐⭐⭐ | +3 | 认证绕过 | WP#3 |\n| COMB-002 | KB-005 | KB-008 | 并行 | ⭐⭐ | +2 | 权限提升 | WP#7+WP#12 |\n| ... | ... | ... | ... | ... | ... | ... | ... |\n```\n\n**要求**：\n\n- 至少识别 **8 个**可行的知识组合\n- 标注创新度和难度提升\n\n### 4.3 需求-知识映射\n\n**根据用户需求，从知识库中筛选匹配的模块**：\n\n```markdown\n## 需求-知识匹配报告\n\n### 用户需求\n- 语言：Python\n- 漏洞：SSTI、逻辑漏洞\n- 场景：OA系统\n- 难度：困难\n\n### 匹配的知识模块（按优先级排序）\n| 模块ID | 匹配度 | 适用性分析 | 计划使用方式 |\n|--------|--------|-----------|-------------|\n| KB-003 | 95% | SSTI沙箱绕过，完全匹配 | 作为主漏洞的核心利用 |\n| KB-008 | 85% | 权限验证逻辑漏洞 | 作为前置步骤 |\n| KB-001 | 80% | 配置文件泄露 | 作为信息收集步骤 |\n| ... | ... | ... | ... |\n\n### 选中的知识组合\n| 组合ID | 适用性 | 创新潜力 | 计划应用 |\n|--------|--------|---------|---------|\n| COMB-005 | 高 | ⭐⭐⭐ | 作为Step 2-4的核心链路 |\n| COMB-012 | 中 | ⭐⭐ | 作为备选方案 |\n\n### 知识迁移计划\n针对每个选中的知识模块，说明如何迁移到新场景：\n\n**KB-003 迁移计划**：\n- 原场景：博客系统的模板渲染\n- 新场景：OA系统的报表生成\n- 迁移调整：\n1. 触发点从\"文章模板\"改为\"报表模板\"\n2. 增加权限检查（OA系统特有）\n3. 沙箱限制从Jinja2改为自定义沙箱\n- 预期难度变化：+2（因为增加了权限层）\n- 创新点：结合OA审批流程的状态机\n```\n\n**检查点**：\n\n- [ ] 至少选择了 **5 个**知识模块用于设计\n- [ ] 至少选择了 **2 个**知识组合\n- [ ] 每个模块都有明确的迁移计划\n- [ ] 知识覆盖了利用链的 **80%** 以上步骤\n",
"required": true
},
{
"id": "5",
"name": "题目设计",
"order": 4,
"output": "利用链、核心代码预写",
"prompt": "\n### 🎨 5.1 设计目标\n\n**核心原则**：\n\n1. **知识应用优先**：每个步骤必须追溯到学习的知识模块\n\n2. **差异化创新**：与学习材料的差异度要求\n- 中等题：≥50%\n- 困难题：≥70%\n\n3. **深度保证**：满足阶段 5.7 的深度标准\n\n4. **趣味性保证**：包含\"啊哈时刻\"和渐进式发现\n\n5. **源码提供决策** ：根据题目特性决定是否提供源码\n\n---\n\n### 🎯 5.2 场景攻击面分析（必须）\n\n**在设计利用链之前，必须深入分析场景的业务特有攻击面**：\n\n#### 1. 核心业务流程分析\n\n列出场景的 3-5 个核心业务流程，例如：\n- **OA系统**：登录 → 发起申请 → 审批 → 归档 → 查询\n- **电商系统**：浏览 → 加购 → 下单 → 支付 → 发货 → 评价\n- **论坛系统**：注册 → 发帖 → 评论 → 私信 → 举报\n- **医疗系统**：预约 → 挂号 → 就诊 → 处方 → 缴费\n\n#### 2. 状态转换点识别\n\n识别业务流程中的关键状态变化：\n- 待审批 → 已审批（审批流程）\n- 未支付 → 已支付（支付流程）\n- 草稿 → 已发布（内容发布）\n- 待处理 → 已完成（工单流程）\n\n#### 3. 权限边界分析\n\n识别不同角色的权限差异：\n- 普通用户 vs 管理员\n- 申请人 vs 审批人\n- 买家 vs 卖家\n- 患者 vs 医生\n\n#### 4. 数据敏感点识别\n\n识别敏感数据的存储和流动路径：\n- 认证凭据（密码、密钥、token）\n- 业务数据（订单、金额、积分）\n- 个人信息（身份、联系方式）\n\n**⚠️ 强制要求**：至少 **1 个利用步骤**必须针对上述分析中的**场景特有点**，而非通用漏洞（如通用的登录SSTI、搜索SQL注入）\n\n---\n\n### 🔀 5.3 多路径设计（必须）\n\n**在确定最终利用链之前，必须设计多种方案并对比选择**：\n\n#### 步骤 1：列出至少 2 种完全不同的利用链方案\n\n每种方案使用**不同的核心漏洞入口**或**不同的利用路径**。\n\n#### 步骤 2：对比评估\n\n| 维度 | 方案 A | 方案 B |\n|------|--------|--------|\n| 场景融合度 | 漏洞与业务逻辑的结合程度 | |\n| 创新度 | 技术组合的新颖程度 | |\n| 趣味性 | 解题过程的探索感 | |\n| 可实现性 | 技术实现的可行性 | |\n\n#### 步骤 3：选择最终方案\n\n**选择标准（按优先级）**：\n1. **场景融合度最高**：漏洞与业务逻辑深度绑定\n2. **创新度最高**：避免常见的利用模式\n3. **趣味性最高**：有\"啊哈时刻\"和探索感\n\n**⚠️ 禁止**：只设计一种方案直接使用\n\n---\n\n### 📊 5.4 利用链模式参考\n\n**避免总是使用相同的利用链模式，参考以下多种模式**：\n\n**模式 A：信息泄露链**\n```\n信息收集 → 敏感信息获取 → 认证绕过 → 目标达成\n```\n\n**模式 B：业务逻辑链**（推荐优先考虑）\n```\n功能探索 → 业务流程分析 → 状态机漏洞/逻辑漏洞 → 权限提升\n```\n\n**模式 C：多点组合链**\n```\n漏洞点 A（低危）+ 漏洞点 B（低危）→ 组合利用 → 高危影响\n```\n\n**模式 D：时序/竞态链**\n```\n正常流程 → 时序分析 → 竞态条件 → 状态篡改\n```\n\n**模式 E：二次触发链**\n```\n数据写入 → 存储 → 二次读取触发 → 漏洞利用\n```\n\n**模式 F：信任边界链**\n```\n低权限入口 → 信任传递 → 高权限上下文 → 目标达成\n```\n\n---\n\n### 📈 5.5 深度评估示例\n\n---\n\n#### 深度 5/10 - 合格步骤（中等题最低要求）\n\n- **SQL 注入绕过黑名单**：需要使用大小写混合 + 注释符绕过关键词过滤\n- **Cookie 伪造**：需要通过 SQL 注入获取 Secret，然后理解 HMAC 签名机制\n- **文件上传绕过**：需要绕过 MIME 类型检查 + 文件扩展名检查（双重防护）\n- **权限提升**：需要理解业务逻辑，利用状态机漏洞\n\n**为什么深度合格**：\n\n- 需要绕过 2 层以上防护\n- 需要理解一定的技术原理\n- 需要组合多个技巧\n\n---\n\n#### 深度 7/10 - 高深度步骤（困难题要求）\n\n- **INSERT SQL 注入**：需要理解 SQL 语法，使用双重编码绕过 `html_entity_decode`\n- **Phar 反序列化**：需要理解 PHP 反序列化机制，构造 Phar 文件，绕过图片检测\n- **竞态条件利用**：需要理解多线程、时序问题，精确控制请求时间\n- **JWT 算法混淆**：需要理解 JWT 结构，利用 `alg: none` 或 RS256→HS256 转换\n\n**为什么深度高**：\n\n- 需要深入理解底层原理\n- 需要组合 3 种以上技术\n- 需要精确控制利用过程\n- 有\"啊哈时刻\"（需要灵光一现）\n\n---\n\n#### 深度 9/10 - 极高深度步骤（困难题的核心步骤）\n\n- **复杂魔术方法链**：需要构造 5 层以上的魔术方法调用链，理解 PHP 对象交互\n- **二次注入 + 时序竞态**：需要先通过注入写入恶意数据，然后利用竞态条件触发\n- **类型混淆 + 反序列化**：需要理解 PHP 类型比较机制，构造特殊对象绕过检查\n- **多系统交互利用**：需要同时利用 Web + Redis + MySQL 的特性组合攻击\n\n**为什么深度极高**：\n\n- 需要非常深入的底层理解\n- 需要创新性的利用方式\n- 需要多个\"啊哈时刻\"\n- 需要查阅文档或源码才能想到\n\n---\n\n#### ⚠️ 常见的\"假深度\"步骤（需要避免）\n\n1. **简单的编码绕过**\n- ❌ 错误：只需要 URL 编码一次就能绕过\n- ✅ 正确：需要多层编码 + 理解解码顺序\n\n2. **弱密码爆破**\n- ❌ 错误：密码是 `admin123`，字典前 100 个就能爆破\n- ✅ 正确：密码需要通过其他漏洞获取，或者是强密码但有提示\n\n3. **直接信息泄露**\n- ❌ 错误：Secret 直接写在配置文件中，通过目录遍历就能读取\n- ✅ 正确：Secret 需要通过 SQL 注入 + 理解表结构才能获取\n\n4. **单一防护绕过**\n- ❌ 错误：只有一个黑名单，绕过后就能利用\n- ✅ 正确：有多层防护，需要逐层绕过\n\n---\n\n### 🔍 5.6 源码提供决策\n\n**在设计题目时，必须明确决定是否提供源码，并确保难度合理**：\n\n#### 决策标准\n\n**必须提供源码的情况**：\n\n- 题目核心考点是代码审计\n- 漏洞点隐藏在复杂的业务逻辑中，黑盒测试难以发现\n- 需要理解底层实现才能构造payload\n\n**可以不提供源码的情况**：\n\n- 题目核心考点是黑盒渗透\n- 漏洞点可以通过功能测试发现\n- 防护机制可以通过试错推断\n- 提供源码会降低难度过多\n\n---\n\n### 🎯 5.7 深度与趣味性设计标准\n\n#### 深度评分标准\n\n| 难度 | 平均深度 | 最高深度 | **最低深度** | 高深度步骤数 | 防护层数 | 趣味性要求 |\n| ---- | -------- | -------- | ------------ | ------------ | -------- | ----------------------------------------- |\n| 中等 | ≥6.0 | ≥8.0 | **≥5.0** | ≥2步≥7.0 | 4-5层 | 2个啊哈时刻 + 1个创新组合 + 1个误导设计 |\n| 困难 | ≥7.5 | ≥9.0 | **≥6.0** | ≥3步≥8.0 | 6+层 | 2个啊哈时刻 + 2个创新组合 + 2个误导设计 |\n\n**🚨 重要**：中等/困难题 **不允许有简单步骤**（深度 <5.0），每一步都必须有深度！\n\n#### ❌ 禁止的表面化设计（中等/困难题）\n\n1. **简单字符串替换绕过** → ✅ 改进：多层递归过滤 + 语义分析\n2. **单一大小写绕过** → ✅ 改进：协议白名单 + 路径规范化\n3. **单点防护机制** → ✅ 改进：多层级独立验证 + 状态关联检查\n4. **直接信息泄露** → ✅ 改进：需要通过漏洞获取信息\n5. **明文注释漏洞点** → ✅ 改进：代码逻辑自然，不显示漏洞提示\n\n#### ✅ 深度设计要素\n\n**中等题**：**每个步骤**满足至少 2 项\n\n- 多重防护组合（≥2 种绕过技术）\n- 上下文依赖利用（理解业务逻辑/框架特性）\n- 状态关联验证（需要前置步骤的特定状态）\n- 深层技术理解（底层原理）\n\n**困难题**：**每个步骤**满足至少 3 项，且包含：\n\n- 非预期路径封堵（≥3 个诱饵路径）\n- 时序与竞态利用\n- 多系统交互\n- 创新组合利用\n\n#### 🎨 趣味性设计技巧\n\n1. **\"啊哈时刻\"**：关键步骤需要灵光一现\n2. **渐进式发现**：每步揭示新信息，避免一次性暴露\n3. **真实场景模拟**：基于真实业务逻辑（OA审批、电商订单、权限管理）\n4. **隐藏的关联性**：表面独立，实际存在隐藏交互\n5. **误导性设计**：诱饵路径（看似可行但不通）\n\n---\n\n### 📝 5.8 设计输出格式\n\n```markdown\n## 题目设计方案\n\n### 基本信息\n- 题目名称：xxx\n- 难度：中等\n- 预计解题时间：2-3 小时\n- 差异度：55%（相比 WP#3、WP#7）\n\n### 源码提供决策\n- **是否提供源码**：是/否\n- **决策理由**：xxx\n- **难度影响**：xxx\n- **平衡措施**：xxx\n\n### 利用链设计\n| 步骤 | 类型 | 技术点 | 深度 | 知识来源 | 创新点 | 防护机制 | 绕过方式 |\n|------|------|--------|------|---------|--------|---------|---------|\n| Step 1 | 信息收集 | 配置泄露 | 3/10 | KB-001 | 改为OA场景 | 路径白名单 | 路径规范化绕过 |\n| Step 2 | 认证绕过 | JWT伪造 | 5/10 | KB-002 | 增加时间戳验证 | 签名验证 | 密钥泄露+时间戳预测 |\n| Step 3 | 权限提升 | 逻辑漏洞 | 7/10 | KB-008 | 结合审批流程 | 状态机验证 | 状态竞态 |\n| Step 4 | 代码执行 | SSTI | 9/10 | KB-003+COMB-005 | 自定义沙箱 | 黑名单过滤 | 多层编码+属性链 |\n\n**平均深度**：6.0/10 ✅\n**最高深度**：9.0/10 ✅\n**最低深度**：3/10 ❌（简单题可接受，中等/困难题不合格）\n**高深度步骤数**：2 步 ≥7.0 ✅\n\n**深度说明**（必须填写）：\n- **Step 1 (3/10)**：为什么是 3/10？因为只需要简单的路径遍历，无需深入理解\n- **Step 2 (5/10)**：为什么是 5/10？因为需要理解 HMAC 签名机制 + 通过 SQL 注入获取密钥（2层技术）\n- **Step 3 (7/10)**：为什么是 7/10？因为需要理解状态机 + 竞态条件 + 业务逻辑（3层技术 + 啊哈时刻）\n- **Step 4 (9/10)**：为什么是 9/10？因为需要构造复杂的沙箱绕过 + 多层编码 + 属性链（4层技术 + 需要查阅文档）\n\n### 知识应用追踪\n- **直接应用**：KB-001, KB-002, KB-003, KB-008（4个）\n- **组合应用**：COMB-005（1个）\n- **创新扩展**：Step 3 的状态竞态（基于 KB-008 创新）\n- **知识应用率**：100%（所有步骤都有知识来源）\n- **差异度分析**：\n- Step 1：30%（场景迁移）\n- Step 2：50%（增加时间戳验证）\n- Step 3：80%（创新的状态竞态）\n- Step 4：60%（自定义沙箱）\n- **总体差异度**：55% ✅\n\n### 深度亮点设计 ⭐\n1. **啊哈时刻 #1**：发现审批流程的状态竞态（Step 3）\n2. **啊哈时刻 #2**：理解自定义沙箱的属性链绕过（Step 4）\n3. **误导设计**：诱饵路径 - 看似可用的 SQL 注入点（实际无法利用）\n4. **隐藏关联**：Step 1 的配置文件包含 Step 2 的密钥提示\n\n### 场景设计\n- 系统类型：OA审批系统\n- 核心功能：报表生成、审批流程\n- 辅助功能：xxx、xxx\n- 无用功能（与漏洞无关，仅为了使系统更加真实或者迷惑选手）：xxx、xxx\n- 真实度：8/10\n- 误导元素：假的管理员登录入口、无用的 API 文档\n\n### 非预期解防护\n1. **防护点 #1**：禁止直接访问 /flag.txt（权限检查）\n2. **防护点 #2**：SSTI 黑名单包含常见 bypass（需要深度理解）\n3. **防护点 #3**：审批流程的状态验证（防止跳步）\n```\n\n### 🔬 5.9 设计可实现性验证\n\n**在进入代码生成前，必须验证设计在技术上可实现：**\n\n#### 验证维度：\n\n**1. 利用链完整性检查**\n\n- [ ] 每一步的输入来源明确（用户输入/前一步输出/题目提供）\n- [ ] 每一步的输出能被下一步使用\n- [ ] 没有循环依赖（需要A获得B，需要B获得A）\n- [ ] 没有信息黑洞（需要的信息无法获得）\n\n**2. 技术栈兼容性检查**\n\n- [ ] 选择的语言/框架支持设计的漏洞利用方式\n- [ ] 防护机制不会完全阻断利用链\n- [ ] 编码/特殊字符处理不会破坏payload\n\n**3. 状态管理可行性**\n\n- [ ] Session/Cookie/Token的传递路径清晰\n- [ ] 多步骤攻击的状态能正确保持\n- [ ] 时序依赖（如竞态条件）在实现上可控\n\n**4. 数据流模拟**\n\n绘制完整的数据流图：\n[用户输入] → [处理函数A] → [中间状态] → [处理函数B] → [漏洞触发] → [FLAG]\n↓ ↓ ↓ ↓ ↓\npayload1 过滤/验证 session存储 权限检查 文件读取\n\n**检查每个箭头：**\n\n- 数据格式是否兼容？\n- 是否有隐式转换？\n- 是否有中间过滤？\n\n**5. 伪代码验证**\n\n为每个关键步骤写伪代码：\n\n```\n# Step 1: 信息收集\ninput: URL参数 ?file=xxx\nprocess: 路径拼接 /var/www/ + file\noutput: 文件内容\ncheck: ✅ 能否读取到敏感文件？\n\n# Step 2: 权限绕过\ninput: 从Step1获得的密钥\nprocess: JWT伪造\noutput: admin token\ncheck: ✅ 密钥格式是否正确？✅ JWT库是否支持？\n\n# Step 3: RCE\ninput: admin token\nprocess: 模板渲染\noutput: 命令执行\ncheck: ✅ 模板引擎是否支持？✅ 沙箱能否绕过？\n```\n\n**6. 常见陷阱检查**\n\n| 陷阱类型 | 检查项 | 示例 |\n| -------- | ---------------------------------- | --------------------------------- |\n| 字符转义 | payload中的特殊字符是否会被转义？ | SQL注入中的单引号、SSTI中的花括号 |\n| 编码问题 | 多层编码/解码是否会破坏payload？ | URL编码、Base64、Unicode |\n| 类型转换 | 弱类型语言的隐式转换是否影响利用？ | PHP的 `==` vs `===` |\n| 长度限制 | payload是否超过字段长度限制？ | 数据库字段、HTTP header |\n| 时序问题 | 多步骤攻击的时序是否可控？ | Session过期、Token时效 |\n| 环境依赖 | 是否依赖特定的库版本/配置？ | Python2 vs Python3 |\n\n**7. 🆕 关键实现细节预写（必须）**\n\n**在设计阶段就必须明确以下技术细节，不能留到代码生成阶段：**\n\n```markdown\n### 关键实现细节\n\n1. **漏洞触发点**\n- 具体使用什么函数/方法触发漏洞？\n- 输入参数的格式是什么？（JSON/Form/Cookie/Header）\n- 输出期望是什么？\n\n2. **核心代码片段**（5-10行伪代码）\n- 展示漏洞如何被触发\n- 如果写不出来，说明设计不可行，需要调整\n\n3. **exp 核心逻辑**（5-10行伪代码）\n- 展示如何构造请求和 payload\n- 确认利用链每一步的数据格式\n\n4. **潜在冲突检查**\n- 模板文件中是否会包含与模板语法冲突的内容？\n- 配置文件中是否有特殊字符需要转义？\n- 多个组件之间是否有冲突？\n```\n\n**8. 🆕 漏洞代码正确性验证（必须）**\n\n**必须明确区分\"安全写法\"和\"漏洞写法\"，避免生成无法触发的漏洞代码：**\n\n```markdown\n### 漏洞代码正确性验证\n\n对于每个漏洞触发点，必须写出：\n\n1. **❌ 安全写法**（不能触发漏洞的写法）\n- 示例：render_template_string(template, user_input=data)\n- 原因：用户输入作为变量传递，不会被解析执行\n\n2. **✅ 漏洞写法**（能触发漏洞的写法）\n- 示例：render_template_string(f'{data}
')\n- 原因：用户输入直接拼接到模板字符串中，会被解析执行\n\n3. **验证问题**\n- 我设计的代码是哪种写法？\n- 如果是安全写法，如何修改为漏洞写法？\n```\n\n**9. 🆕 exp 执行流程预演（必须）**\n\n**在写 exp 代码前，必须模拟完整的攻击流程：**\n\n```markdown\n### exp 执行流程预演\n\n1. **攻击者身份**\n- 需要什么权限？（匿名/普通用户/admin）\n- 如何获取该权限？（注册/已知密码/漏洞提权）\n\n2. **请求序列**（按顺序列出每个请求）\n| 步骤 | 请求方法 | 路径 | 参数 | 期望响应 |\n|------|---------|------|------|---------|\n| 1 | POST | /login | username=xxx | 302 + cookie |\n| 2 | POST | /vuln | payload=xxx | 200 + 泄露数据 |\n| ... | ... | ... | ... | ... |\n\n3. **flag 回显路径**（必须明确）\n- RCE 执行后，flag 如何传递给攻击者？\n- 选项：HTTP响应 / 文件读取 / DNS外带 / 时间盲注\n- 如果选择文件读取，如何再次读取该文件？\n\n4. **潜在失败点**\n- 哪些步骤可能失败？\n- 失败后如何检测和恢复？\n```\n\n**⚠️ 如果无法写出关键代码片段，必须简化设计或更换技术方案**\n\n**验证输出格式：**\n\n```\n## 可实现性验证报告\n\n### 利用链完整性：✅ 通过\n- Step 1→2：通过文件读取获得密钥 ✅\n- Step 2→3：使用密钥伪造token ✅\n- Step 3→FLAG：使用token访问admin接口 ✅\n\n### 技术栈兼容性：✅ 通过\n- Python Flask支持SSTI ✅\n- Jinja2模板引擎可利用 ✅\n\n### 潜在问题：⚠️ 1个\n- 问题1：密钥可能包含特殊字符，需要处理\n- 解决方案：使用Base64编码存储\n\n### 数据流图：\n[已绘制，见上方]\n\n### 伪代码验证：✅ 通过\n[已完成，见上方]\n\n### 结论：✅ 设计可实现，可以进入代码生成阶段\n```\n\n**若验证失败 → 返回5.8重新设计利用链**\n\n---\n\n\n",
"required": true
},
{
"id": "6",
"name": "质量检查与优化",
"order": 5,
"output": "验证清单",
"prompt": "\n### ✅ 6.1 检查清单（优先级排序）\n\n#### 🚫 一票否决项（必须通过）\n\n1. **知识应用度检查**\n- [ ] 所有步骤都有明确的知识来源（KB-XXX 或 COMB-XXX）\n- [ ] 知识应用率 ≥80%\n- [ ] 差异度达标（简单≥30%，中等≥50%，困难≥70%）\n\n2. **源码提供决策检查**\n- [ ] 已明确决定是否提供源码\n- [ ] 决策理由充分（符合决策标准）\n- [ ] 难度平衡措施到位\n- [ ] 如果不提供源码：黑盒可测\n\n3. **深度达标检查**\n- [ ] 平均深度达标（中等≥6.0，困难≥7.5）\n- [ ] 最高深度达标（中等≥8.0，困难≥9.0）\n- [ ] **最低深度达标**（中等≥5.0，困难≥6.0）\n- [ ] 高深度步骤数达标\n- [ ] **中等/困难题无简单步骤**（所有步骤深度≥5.0）\n- [ ] **逐步检查每个步骤的深度**：列出每个步骤的深度评分，确保无遗漏\n\n4. **趣味性检查**\n- [ ] 包含至少 1 个\"啊哈时刻\"\n- [ ] 有渐进式发现（不是一次性暴露所有信息）\n- [ ] 有误导设计或隐藏关联\n\n5. **技术深度检查**\n- [ ] 中等/困难题：每个绕过点满足深度设计要素（见阶段 5.7）\n- [ ] 避免表面化设计（见阶段 5.7 禁止列表）\n\n6. **场景真实性检查**\n- [ ] 业务逻辑合理（不是为了漏洞而设计）\n\n7. **场景融合度检查**（新增）\n- [ ] 至少 1 个利用步骤针对**场景特有功能**（非通用的登录/搜索/上传）\n- [ ] 漏洞触发点与业务流程有逻辑关联\n- [ ] 已完成场景攻击面分析（阶段 5.2）\n\n8. **多样性检查**（新增）\n- [ ] 已设计并对比至少 2 种利用链方案（阶段 5.3）\n- [ ] 最终方案不是最\"常见\"的利用模式\n- [ ] 利用链模式不是简单的\"信息泄露→认证绕过→RCE\"\n\n9. **设计可实现性检查**\n- [ ] 利用链没有循环依赖\n- [ ] 所有需要的信息都能获得\n- [ ] 技术栈支持设计的利用方式\n- [ ] 已完成数据流模拟\n- [ ] 已完成伪代码验证\n- [ ] 已识别并解决潜在陷阱（字符转义、编码、类型转换等）\n\n#### 🆕 6.2 实现风险评估（必须通过）\n\n**在进入代码生成前，评估设计的实现风险：**\n\n| 风险类型 | 检查项 | 状态 |\n|---------|-------|------|\n| **技术复杂度** | 设计中是否有过于复杂的技术点？能否简化？ | |\n| **依赖风险** | 是否依赖特定版本的库/框架？版本兼容性如何？ | |\n| **环境差异** | 本地开发环境和 Docker 容器环境是否一致？ | |\n| **组件冲突** | 多个组件/功能之间是否可能冲突？ | |\n| **文件内容冲突** | 生成的文件内容是否会与框架语法冲突？ | |\n\n**⚠️ 如果风险过高（超过 2 项高风险），应该简化设计**\n\n10. **用户漏洞覆盖检查**（一票否决）\n- [ ] 用户要求的**所有漏洞类型**都在利用链中被使用\n- [ ] 每个漏洞类型在利用链中有**明确的步骤编号**\n- [ ] 如果某个漏洞类型无法使用，必须**明确说明原因**并获得用户确认\n- **验证格式**：\n```\n用户要求漏洞: [SSTI, SSRF, PHP反序列化]\n- SSTI: Step 3 ✅\n- SSRF: Step 2 ✅\n- PHP反序列化: Step 4 ✅\n覆盖率: 3/3 = 100% ✅\n```\n\n---\n\n### 📈 6.3 如何提升步骤深度（修复指南）\n\n**当发现某个步骤深度不够时，使用以下方法提升**：\n\n#### 方法 1：增加防护层数\n\n**原版**（深度 3/10）：\n\n- SQL 注入：直接 `' OR 1=1--` 就能绕过\n\n**提升后**（深度 5/10）：\n\n- 增加关键词黑名单：需要使用大小写混合绕过\n- 增加注释符过滤：需要使用 `/**/` 绕过\n- 增加长度限制：需要精简 payload\n\n**提升后**（深度 7/10）：\n\n- 再增加 WAF 规则：需要使用编码绕过\n- 再增加语义分析：需要理解 SQL 解析顺序\n- 再增加时间延迟检测：需要使用盲注技巧\n\n---\n\n#### 方法 2：增加前置依赖\n\n**原版**（深度 4/10）：\n\n- Cookie 伪造：Secret 直接写在配置文件中，通过目录遍历就能读取\n\n**提升后**（深度 6/10）：\n\n- Secret 存储在数据库中：需要先通过 SQL 注入获取\n- Secret 需要解密：需要理解加密算法\n- Secret 有时间戳验证：需要预测或同步时间\n\n---\n\n#### 方法 3：增加技术组合\n\n**原版**（深度 5/10）：\n\n- 文件上传：绕过 MIME 类型检查即可\n\n**提升后**（深度 7/10）：\n\n- 需要绕过 MIME 类型检查\n- 需要绕过文件扩展名检查\n- 需要绕过文件内容检查（如 `getimagesize()`）\n- 需要利用 Phar 反序列化触发\n\n---\n\n#### 方法 4：增加底层理解要求\n\n**原版**（深度 4/10）：\n\n- SSTI：直接 `{{7*7}}` 就能执行\n\n**提升后**（深度 8/10）：\n\n- 有黑名单过滤：需要理解 Jinja2 语法，使用属性访问绕过\n- 有沙箱限制：需要理解 Python 对象模型，构造属性链\n- 需要查阅文档：找到可以利用的内置函数\n- 需要多层编码：绕过 WAF 检测\n\n---\n",
"required": true,
"skip_forbidden": true
},
{
"id": "7",
"name": "代码生成与验证",
"order": 6,
"output": "后端代码、Docker 文件",
"prompt": "### 7.0 代码生成前强制自检（必须执行）\n\n**在写任何代码之前，必须逐项检查以下内容**：\n\n1. **黑名单/过滤器一致性检查**：\n- 列出设计中所有的防护机制（黑名单、过滤器、WAF 等）\n- 列出设计中所有的绕过 payload\n- **逐一验证**：每个 payload 是否能通过对应的防护机制？\n- 如果 payload 会被自己设计的黑名单拦截，**必须在写代码前修改设计**\n\n2. **利用链可达性检查**：\n- 从 Step 1 到最后一步，逐步模拟数据流\n- 确认每一步的输入都能从上一步获得\n- 确认每一步的输出都能传递给下一步\n\n3. **技术栈兼容性检查**：\n- 确认使用的函数/方法在目标语言版本中存在\n- 确认使用的库/框架版本支持设计的功能\n\n**⚠️ 常见错误示例（必须避免）**：\n- ❌ 设计用 `eval()` 执行代码，但黑名单包含 `eval` → 自相矛盾\n- ❌ 设计用 `constructor` 绕过，但黑名单包含 `constructor` → 自相矛盾\n- ❌ 设计污染 `__proto__`，但 JSON 解析器过滤了 `__proto__` → 无法触发\n\n**✅ 正确做法**：\n- 如果 payload 需要用 `eval`，则黑名单不能包含 `eval`（或提供其他绕过方式）\n- 如果黑名单必须包含某关键词，则 payload 必须使用 Unicode 编码等方式绕过\n\n### 7.1 生成原则\n\n1. **完整性**：包含所有设计的功能点和漏洞点\n2. **零注释**：代码中禁止任何注释\n3. **真实性**：模拟真实业务逻辑\n4. **隐蔽性**：漏洞点自然隐藏在业务逻辑中\n\n**提供源码时**：禁止硬编码管理员密码\n**不提供源码时**：可以硬编码\n\n### 7.2 增量生成顺序（每步必须验证）\n\n**⚠️ 本阶段只生成题目代码和 Docker 文件，exp.py 和 writeup.md 在阶段 9 生成**\n\n1. **后端代码**\n- 检查：所有 import 语句是否完整\n- 检查：路由定义是否正确（路径、方法）\n- 检查：漏洞触发点是否使用\"漏洞写法\"\n\n2. **依赖文件**\n- 检查：requirements.txt 包含所有导入的模块\n- 检查：版本号是否明确指定\n\n3. **前端文件**\n- 检查：表单 action 路径与后端路由一致\n- 检查：input name 与后端参数名一致\n- 检查：模板语法不与框架冲突\n\n4. **Docker 文件**\n- 检查：EXPOSE 端口与应用监听端口一致\n- 检查：docker-compose ports 映射正确\n- 检查：COPY 路径正确\n\n**⚠️ 每步生成后立即验证，发现问题立即修复**\n\n### 7.3 文件结构\n\n```\noutput/{timestamp}_{题目名称}/\n├── docker/\n│ ├── docker-compose.yml\n│ └── web/\n│ ├── Dockerfile\n│ ├── files/ (flag.sh, start.sh)\n│ └── src/\n```\n\n**注意：exp.py 和 writeup.md 在阶段 9 生成**\n\n### 7.4 核心文件要求\n\n**docker-compose.yml**：\n- 外部端口：随机 42500-42600\n- 只允许 1 个 web 容器\n- 设置唯一 container_name\n\n**Dockerfile**：\n- 使用官方镜像\n- 包含 `ENV DASFLAG DASCTF{test12345}`\n- 优先使用国内源\n\n**flag.sh**：\n```bash\n#!/bin/bash\necho $DASFLAG > /flag.txt\nexport DASFLAG=nonono\nrm -f /flag.sh\n```\n\n### 7.5 设计-实现一致性验证\n\n生成完成后，验证：\n- [ ] 每个设计步骤都有对应的代码实现\n- [ ] 漏洞触发点使用的是\"漏洞写法\"\n- [ ] 路由路径、参数名与阶段 5 设计一致\n",
"required": true
},
{
"id": "8",
"name": "Docker 环境构建",
"order": 7,
"output": "容器验证",
"prompt": "### 8.1 Docker 构建\n\n**严格遵循 DASCTF 标准**：\n\n- docker-compose.yml：仅使用 `image`, `build`, `ports`，**禁止多容器架构**\n- Dockerfile：使用官方镜像，包含 `ENV DASFLAG DASCTF{test12345}` 和 `EXPOSE 80`\n- flag.sh：写入 FLAG，覆盖环境变量，删除自身\n- start.sh：按顺序启动服务，使用 `tail -f /dev/null`\n- Dockerfile：相关环境的安装优先使用国内源，包括apt、pip等，避免过慢\n\n**⚠️ 容器数量限制**：\n- 只允许 **1 个 web 容器**，flag 必须在 web 容器内的 `/flag.txt`\n- **禁止**：多容器架构（如 web + redis、web + mysql 分离等）\n- 如需 Redis/MySQL，必须在同一容器内启动\n\n### 8.2 分层验证流程（必须按顺序执行）\n\n**不要一次性测试所有功能！按以下顺序分层验证：**\n\n#### 第一层：容器启动验证\n```bash\n# 使用唯一项目名启动（避免与其他容器冲突）\ndocker-compose -p ctf_test up -d --build\n# 只查看当前项目的容器状态（不要用 docker ps，会看到其他项目的容器）\ndocker-compose -p ctf_test ps\n```\n**如果失败**：检查 Dockerfile、依赖安装、start.sh\n**⚠️ 重要**：必须使用 `docker-compose -p ctf_test ps` 而不是 `docker ps`，否则会误判其他项目的容器\n\n#### 第二层：服务可用性验证\n```bash\ncurl http://localhost:端口/ # 确认返回 200\n```\n**如果失败**：检查应用启动命令、端口配置\n\n#### 第三层：基础功能验证\n- 测试正常功能（如注册、登录）是否工作\n- **不涉及漏洞利用**\n**如果失败**：检查路由、数据库、Session 配置\n\n#### 第四层：漏洞触发验证\n- 使用**最简单的 payload** 测试漏洞是否可触发\n- 例如：SSTI 测试 `{{7*7}}`，SQL 注入测试 `' or 1=1--`\n**如果失败**：检查漏洞触发点代码、过滤逻辑\n\n#### 第五层：完整 exp 验证\n```bash\npython3 ../exp.py localhost 端口 DASCTF{test12345}\n```\n**如果失败**：检查 exp.py 与后端代码的一致性\n\n**⚠️ 每层验证通过后再进入下一层。失败时立即修复当前层，不要跳层。**\n\n### 8.3 测试清单(需要输出)\n\n- [ ] Docker 容器能够正常启动\n- [ ] 前端页面正常显示\n- [ ] **前端页面无测试账号、管理员账号等信息**\n- [ ] **源码注释无漏洞点、绕过方法等泄露**\n- [ ] exp.py 能够成功获取 FLAG\n- [ ] 跳步验证通过（无非预期解）\n- [ ] **信息泄露检查**\n- [ ] 前端页面无测试账号、管理员账号、敏感路径等信息\n- [ ] 前端页面无漏洞提示、FLAG路径等信息\n- [ ] 源码注释无漏洞点、绕过方法、敏感信息等泄露\n- [ ] 源码注释无解题步骤提示\n\n**若测试失败 → 修复代码并重新测试**\n",
"required": true
},
{
"id": "9",
"name": "exp 和 writeup",
"order": 8,
"output": "exp.py、writeup.md",
"prompt": "**⚠️ 只有阶段 8 测试全部通过后，才能进入本阶段**\n\n### 9.1 完善 exp.py\n\n基于阶段 5.4 的简易 exp 草稿，完善为标准格式：\n\n```python\n#!/usr/bin/python\n# -*- coding: utf-8 -*-\nimport re, sys, requests\n\nHOST, PORT, FLAG = sys.argv[1:4]\n\ndef exp(ip, port):\n# 完整 exploit 流程\nr = requests.get(f\"http://{ip}:{port}/...\")\nflag = re.findall('DASCTF{(.*?)}', r.text)[0]\nreturn flag\n\nif __name__ == '__main__':\nassert exp(HOST, PORT) == FLAG\nprint(\"Pass!\")\n```\n\n### 9.2 运行 exp.py 验证\n\n```bash\ncd output/{timestamp}_{题目名称}/\npython3 exp.py localhost 端口 test12345\n```\n\n**⚠️ 必须输出 `Pass!` 才能继续编写 writeup**\n\n如果测试失败：\n1. 检查 exp.py 的请求路径、参数名是否与后端一致\n2. 检查 payload 是否被过滤\n3. 修复后重新运行测试\n\n### 9.3 编写 writeup.md（严格按照如下格式）\n\n```markdown\n# 题目名 的解题思路\n\n## 题目信息\n| 题目名 | 题目描述 | 类型 | 预计解题时间 | 难度 | 是否提供源码 |\n| :----: | :------: | :--: | :----------: | :--: | :--: |\n| pooop | 一段有趣的描述或者背景（见下方规范），长度在50-200字之间 | WEB | 1-2小时 | 用户填写的要求中的难度 |是|\n\n**⚠️ 题目描述规范（严格遵守）**：\n- ❌ **禁止**：提及具体漏洞类型（如\"原型链污染\"、\"SQL注入\"、\"反序列化\"、\"SSRF\"、\"SSTI\"、\"XSS\"、\"文件上传\"、\"命令执行\"、\"RCE\"等）\n- ❌ **禁止**：暗示技术栈细节（如\"JWT认证\"、\"Redis缓存\"、\"Node.js特性\"等）\n- ❌ **禁止**：暗示攻击路径（如\"普通用户能否获取管理员权限\"、\"评论处理存在缺陷\"等）\n- ❌ **禁止**：使用\"漏洞\"、\"绕过\"、\"提权\"、\"污染\"、\"逃逸\"、\"沙箱\"、\"注入\"、\"执行\"等敏感词汇\n- ❌ **禁止**：在题目名称中暗示漏洞类型（如\"BlogPollution\"暗示污染漏洞）\n- ✅ **应该**：只描述业务场景和背景故事\n- ✅ **应该**：使用模糊的挑战性描述（如\"你能发现其中的秘密吗？\"）\n- ✅ **应该**：题目名称使用中性的业务名称（如\"TechBlog\"、\"BlogHub\"等）\n\n**好的示例**：\n> 某公司新上线了一套HR管理系统，用于日常人事管理。作为新入职的安全工程师，你被要求对系统进行安全评估。\n\n**坏的示例**（禁止）：\n> HR管理系统权限提升与机密泄露...系统采用JWT认证...普通员工能否通过漏洞获取FLAG？\n> 博客平台的评论和元数据处理存在深层次的设计缺陷...原型链污染...远程命令执行...\n\n## FLAG\n* 动态 flag\n\n## 知识点\n1. xxx\n\n## 解题步骤（要足够详细）\n1. ...\n```\n\n### 9.4 writeup 要求\n\n- **题目描述**：50-200字，禁止提及漏洞类型\n- **解题步骤**：详细，基于实际测试\n- **payload**：必须是实际可用的\n\n\n\n### 附录 A：常见错误预防\n\n| 错误类型 | 预防措施 |\n|---------|---------|\n| 模板路径错误 | 确保文件在 `templates/` 目录下 |\n| 端口不一致 | Dockerfile EXPOSE 与 docker-compose ports 保持一致 |\n| 导入缺失 | 检查 requirements.txt 包含所有导入的模块 |\n| 漏洞无法触发 | 确认使用\"漏洞写法\"而非\"安全写法\" |\n| payload 被过滤 | 确认黑名单不包含 payload 中的关键字符 |\n| 路由不匹配 | 确认 exp.py 请求路径与后端路由完全一致 |\n| 参数名不匹配 | 确认前端 input name、exp 参数名、后端参数名三者一致 |\n\n### 附录 B：代码生成前最终检查（必须通过）\n\n**在生成每个文件前，大声回答以下问题：**\n\n#### 后端代码\n```\n□ 我用的是什么框架？版本是多少？\n□ 漏洞触发点在哪一行？用的是\"漏洞写法\"还是\"安全写法\"？\n□ 所有 import 都写了吗？\n□ 路由路径是什么？请求方法是 GET 还是 POST？\n□ 接收参数用的是什么名字？\n```\n\n#### exp.py\n```\n□ 请求的 URL 路径和后端路由完全一致吗？\n□ 请求方法和后端一致吗？\n□ 参数名和后端接收的参数名一致吗？\n□ payload 会被黑名单过滤吗？\n□ 如何从响应中提取 flag？正则表达式对吗？\n```\n\n#### Docker\n```\n□ 应用监听的端口是多少？\n□ Dockerfile 的 EXPOSE 端口一致吗？\n□ docker-compose 的 ports 映射正确吗？\n□ COPY 的源路径和目标路径都对吗？\n□ start.sh 中启动命令正确吗？\n```\n\n**⚠️ 如果任何一个问题回答不上来，说明设计不够清晰，需要返回阶段 3 补充**\n",
"required": true
},
{
"id": "10",
"name": "成品输出",
"order": 9,
"output": "最终文件结构",
"prompt": "删除额外的测试文件，并输出：\n```\n✅ 题目生成完成！\noutput/{timestamp}_{题目名称}/\n├── docker/\n│ ├── docker-compose.yml\n│ └── web/\n│ ├── Dockerfile\n│ ├── files/ (flag.sh, start.sh, db.sql)\n│ └── src/具体的源代码 (结构清晰，层次分明，前后端分离)\n├── exp.py\n└── writeup.md\n\n```\n\n不要输出任何上述内容以外的内容",
"required": true
}
]
},
"入门": {
"rules": {
"depth_range": [
1.5,
4
],
"diff_rate": 0.2,
"max_count": 1,
"writeup_count": 5
},
"stages": [
{
"fixed_position": true,
"id": "1",
"name": "用户输入需求",
"order": 0,
"output": "语言、漏洞、场景、难度",
"prompt": "**选择顺序**：语言 → 难度 → 漏洞 → 场景\n\n**第一步：选择语言**（如 Python、PHP、Node.js）\n\n**第二步：选择难度**\n| 难度 | 允许漏洞数量 | writeup 总数 |\n|------|-------------|-------------|\n| 入门 | 1 个 | 5 篇 |\n| 简单 | 1-2 个 | 5 篇 |\n\n**第三步：选择漏洞**（根据难度限制数量）\n\n**第四步：选择场景**（如留言板、博客、OA系统）\n\n**示例**：\n```\n语言：Python\n难度：简单（最多2个漏洞）\n漏洞：SQL注入\n场景：留言板\n```\n",
"required": true,
"system_stage": true
},
{
"condition": "knowledge_count > 1",
"id": "2",
"name": "漏洞主次分类",
"order": 1,
"output": "主漏洞/辅助漏洞分配",
"prompt": "**如果用户选择了多个漏洞**（简单难度允许2个）：\n- **主漏洞**（1 个）：核心考点，分配 3 篇 writeup\n- **辅助漏洞**（0-1 个）：辅助利用，分配 2 篇 writeup\n\n**入门难度只允许1个漏洞，跳过此阶段**\n",
"required": false
},
{
"description": "根据用户输入和配置的脚本，从知识库中筛选并获取相关的知识点和 Writeup",
"id": "3",
"knowledge_script_code": "",
"knowledge_script_instruction": "",
"knowledge_script_name": "",
"knowledge_script_path": "",
"name": "知识库获取",
"order": 2,
"output_format": "json",
"prompt": "### 3.1 获取学习材料（必须使用 choice.py）\n*⚠️ 重要：必须使用 Bash 工具运行 choice.py 获取 writeup，禁止使用 WebSearch/WebFetch**\n\n```bash\npython3 data/scripts/choice.py --difficulty=<难度> --count=<数量> \"漏洞名称\"\n```\n\n**⚠️ 漏洞名称必须使用用户输入的完整名称，禁止简化或缩写！**\n- ✅ 正确：`\"SSTI模板注入\"` `\"SQL注入\"` `\"文件上传漏洞\"`\n- ❌ 错误：`\"SSTI\"` `\"SQL\"` `\"文件上传\"`\n\n**示例**：\n```bash\npython3 data/scripts/choice.py --difficulty=简单 --count=3 \"SQL注入\"\npython3 data/scripts/choice.py --difficulty=简单 --count=2 \"信息泄露\"\npython3 data/scripts/choice.py --difficulty=简单 --count=5 \"SSTI模板注入\"\n```\n\n**choice.py 会输出选中的 writeup 文件名，然后使用 Read 工具读取 `data/writeups` 目录下对应的 .md 文件**\n",
"required": true,
"system_prompt": "根据用户输入的需求，使用配置的知识库筛选脚本，从知识库中获取相关的知识点和 Writeup 文件。",
"system_stage": true,
"user_extension": ""
},
{
"id": "4",
"name": "知识整理",
"order": 3,
"output": "可借鉴技巧清单",
"prompt": "**输出可借鉴技巧清单**（简化版）：\n\n```markdown\n## 可借鉴技巧清单\n\n| 技巧 | 来源 | 代码片段 | 适用场景 |\n|------|------|---------|---------|\n| Flask SSTI触发 | WP#1 | `render_template_string(f'...')` | Python Web |\n| SQL注入绕过 | WP#2 | `' OR 1=1--` | 登录表单 |\n```\n\n**要求**：至少提取 3 个可借鉴的代码片段\n",
"required": true
},
{
"id": "5",
"name": "题目设计",
"order": 4,
"output": "利用链、核心代码预写",
"prompt": "### 5.1 设计目标\n\n- **差异度**：入门 ≥20%，简单 ≥30%\n- **深度**：入门 1.5-4.0，简单 2.5-5.0\n- **趣味性**：入门 0-1 个啊哈时刻，简单 1 个啊哈时刻\n\n### 5.2 利用链设计\n\n```markdown\n| 步骤 | 类型 | 技术点 | 深度 | 知识来源 |\n|------|------|--------|------|---------|\n| Step 1 | 信息收集 | robots.txt | 1/10 | WP#1 |\n| Step 2 | 漏洞利用 | SQL注入 | 3/10 | WP#2 |\n```\n\n### 5.3 核心代码预写（必须！）\n\n**在设计阶段就必须写出真实的漏洞代码（非伪代码）**：\n\n```markdown\n### 漏洞触发代码（5-10行真实代码，包含导入）\n\n❌ 安全写法（不能触发）：\n```python\ncursor.execute(\"SELECT * FROM users WHERE id = ?\", (user_id,))\n```\n\n✅ 漏洞写法（能触发）：\n```python\ncursor.execute(f\"SELECT * FROM users WHERE id = {user_id}\")\n```\n\n### exp 核心代码（5-10行真实代码）\n```python\nimport requests\npayload = \"1 OR 1=1--\"\nr = requests.get(f\"{url}/user?id={payload}\")\n```\n\n### 依赖清单\n- Flask==2.0.1\n- requests==2.28.0\n```\n\n**⚠️ 如果写不出来，说明设计不可行，需要调整**\n\n### 5.3.1 代码可运行性自检\n\n在写完核心代码后，回答以下问题：\n\n1. **导入完整吗？** 代码中用到的所有模块都有 import 吗？\n2. **路由正确吗？** exp 请求的路径和后端定义的路由一致吗？\n3. **参数名一致吗？** exp 发送的参数名和后端接收的参数名一致吗？\n4. **响应格式对吗？** exp 期望的响应格式和后端返回的格式一致吗？\n\n### 5.4 简易 exp 草稿（用于 Docker 测试）\n\n**在设计阶段输出简易 exp 草稿，用于后续 Docker 测试验证**：\n\n```python\n# 简易 exp 草稿（仅用于测试，阶段 7 会完善）\nimport requests\n\nurl = \"http://localhost:端口\"\n# Step 1: xxx\nr1 = requests.get(f\"{url}/路径\")\n# Step 2: 漏洞利用\npayload = \"xxx\"\nr2 = requests.post(f\"{url}/漏洞路径\", data={\"参数\": payload})\n# 预期结果：能看到 flag\nprint(r2.text)\n```\n\n### 5.5 设计摘要\n\n```\n### 设计摘要\n- 题目名称：XXX\n- 利用链：Step1 -> Step2\n- 黑名单：xxx（如果有）\n- 关键 payload：xxx\n- 容器端口：5000\n```\n",
"required": true
},
{
"id": "6",
"name": "质量检查",
"order": 5,
"output": "验证清单",
"prompt": "### 检查清单\n\n- [ ] **深度达标**：平均深度、最高深度符合要求\n- [ ] **漏洞覆盖**：用户要求的所有漏洞都在利用链中\n- [ ] **代码可行**：阶段 5.3 的核心代码能正常运行\n- [ ] **payload 兼容**：黑名单不会阻断 payload\n\n**若检查失败 → 返回阶段 5 修改**\n",
"required": true,
"skip_forbidden": true
},
{
"id": "7",
"name": "代码生成",
"order": 6,
"output": "后端代码、Docker 文件",
"prompt": "### 7.1 生成原则\n\n1. **完整性**：包含所有设计的功能点和漏洞点\n2. **零注释**：代码中禁止任何注释\n3. **真实性**：模拟真实业务逻辑\n4. **隐蔽性**：漏洞点自然隐藏在业务逻辑中\n\n**提供源码时**：禁止硬编码管理员密码\n**不提供源码时**：可以硬编码\n\n### 7.2 增量生成顺序（每步必须验证）\n\n**⚠️ 本阶段只生成题目代码和 Docker 文件，exp.py 和 writeup.md 在阶段 7 生成**\n\n1. **后端代码**\n- 检查：所有 import 语句是否完整\n- 检查：路由定义是否正确（路径、方法）\n- 检查：漏洞触发点是否使用\"漏洞写法\"\n\n2. **依赖文件**\n- 检查：requirements.txt 包含所有导入的模块\n- 检查：版本号是否明确指定\n\n3. **前端文件**\n- 检查：表单 action 路径与后端路由一致\n- 检查：input name 与后端参数名一致\n- 检查：模板语法不与框架冲突\n\n4. **Docker 文件**\n- 检查：EXPOSE 端口与应用监听端口一致\n- 检查：docker-compose ports 映射正确\n- 检查：COPY 路径正确\n\n**⚠️ 每步生成后立即验证，发现问题立即修复**\n\n### 7.3 文件结构\n\n```\noutput/{timestamp}_{题目名称}/\n├── docker/\n│ ├── docker-compose.yml\n│ └── web/\n│ ├── Dockerfile\n│ ├── files/ (flag.sh, start.sh)\n│ └── src/\n```\n\n**注意：exp.py 和 writeup.md 在阶段 9 生成**\n\n### 7.4 核心文件要求\n\n**docker-compose.yml**：\n- 外部端口：随机 42500-42600\n- 只允许 1 个 web 容器\n- 设置唯一 container_name\n\n**Dockerfile**：\n- 使用官方镜像\n- 包含 `ENV DASFLAG DASCTF{test12345}`\n- 优先使用国内源\n\n**flag.sh**：\n```bash\n#!/bin/bash\necho $DASFLAG > /flag.txt\nexport DASFLAG=nonono\nrm -f /flag.sh\n```\n\n### 7.5 设计-实现一致性验证\n\n生成完成后，验证：\n- [ ] 每个设计步骤都有对应的代码实现\n- [ ] 漏洞触发点使用的是\"漏洞写法\"\n- [ ] 路由路径、参数名与阶段 5 设计一致\n",
"required": true
},
{
"id": "8",
"name": "Docker 构建与测试",
"order": 7,
"output": "容器验证",
"prompt": "### 8.1 分层验证（按顺序）\n\n1. **容器启动**：`docker-compose -p ctf_test up -d --build`\n2. **服务可用**：`curl http://localhost:端口/`\n3. **基础功能**：测试正常功能（注册、登录）\n4. **漏洞触发**：使用阶段 3.4 的简易 exp 草稿测试漏洞是否可触发\n\n**⚠️ 每层通过后再进入下一层，失败时立即修复代码，不要继续**\n\n### 8.2 测试清单\n\n- [ ] Docker 容器正常启动\n- [ ] 前端页面正常显示\n- [ ] 前端无测试账号泄露\n- [ ] 简易 exp 能触发漏洞并获取 FLAG\n\n**⚠️ 必须全部通过后才能进入阶段 9**\n",
"required": true
},
{
"id": "9",
"name": "exp 和 writeup",
"order": 8,
"output": "exp.py、writeup.md",
"prompt": "**⚠️ 只有阶段 8 测试全部通过后，才能进入本阶段**\n\n### 9.1 完善 exp.py\n\n基于阶段 5.4 的简易 exp 草稿，完善为标准格式：\n\n```python\n#!/usr/bin/python\n# -*- coding: utf-8 -*-\nimport re, sys, requests\n\nHOST, PORT, FLAG = sys.argv[1:4]\n\ndef exp(ip, port):\n# 基于简易 exp 草稿完善\nr = requests.get(f\"http://{ip}:{port}/...\")\nflag = re.findall('DASCTF{(.*?)}', r.text)[0]\nreturn flag\n\nif __name__ == '__main__':\nassert exp(HOST, PORT) == FLAG\nprint(\"Pass!\")\n```\n\n### 9.2 运行 exp.py 验证\n\n```bash\ncd output/{timestamp}_{题目名称}/\npython3 exp.py localhost 端口 test12345\n```\n\n**⚠️ 必须输出 `Pass!` 才能继续编写 writeup**\n\n如果测试失败：\n1. 检查 exp.py 的请求路径、参数名是否与后端一致\n2. 检查 payload 是否被过滤\n3. 修复后重新运行测试\n\n### 9.3 编写 writeup.md（严格按照如下格式）\n\n```markdown\n# 题目名 的解题思路\n\n## 题目信息\n| 题目名 | 题目描述 | 类型 | 预计解题时间 | 难度 | 是否提供源码 |\n| :----: | :------: | :--: | :----------: | :--: | :--: |\n| 题目名 | 一段有趣的描述或背景（50-200字，禁止提及漏洞类型） | WEB | 1-2小时 | 简单 | 是 |\n\n## 知识点\n1. xxx\n2. xxx\n\n## 解题步骤\n\n### Step 1: xxx\n（基于实际测试过程描述）\n\n### Step 2: xxx\n（包含实际的 payload）\n\n## Flag\nDASCTF{test12345}\n```\n\n### 9.4 writeup 要求\n\n- **题目描述**：50-200字，禁止提及漏洞类型\n- **解题步骤**：详细，基于实际测试\n- **payload**：必须是实际可用的\n\n\n\n\n\n\n### 附录 A：常见错误预防\n\n| 错误类型 | 预防措施 |\n|---------|---------|\n| 模板路径错误 | 确保文件在 `templates/` 目录下 |\n| 端口不一致 | Dockerfile EXPOSE 与 docker-compose ports 保持一致 |\n| 导入缺失 | 检查 requirements.txt 包含所有导入的模块 |\n| 漏洞无法触发 | 确认使用\"漏洞写法\"而非\"安全写法\" |\n| payload 被过滤 | 确认黑名单不包含 payload 中的关键字符 |\n| 路由不匹配 | 确认 exp.py 请求路径与后端路由完全一致 |\n| 参数名不匹配 | 确认前端 input name、exp 参数名、后端参数名三者一致 |\n\n### 附录 B：代码生成前最终检查（必须通过）\n\n**在生成每个文件前，大声回答以下问题：**\n\n#### 后端代码\n```\n□ 我用的是什么框架？版本是多少？\n□ 漏洞触发点在哪一行？用的是\"漏洞写法\"还是\"安全写法\"？\n□ 所有 import 都写了吗？\n□ 路由路径是什么？请求方法是 GET 还是 POST？\n□ 接收参数用的是什么名字？\n```\n\n#### exp.py\n```\n□ 请求的 URL 路径和后端路由完全一致吗？\n□ 请求方法和后端一致吗？\n□ 参数名和后端接收的参数名一致吗？\n□ payload 会被黑名单过滤吗？\n□ 如何从响应中提取 flag？正则表达式对吗？\n```\n\n#### Docker\n```\n□ 应用监听的端口是多少？\n□ Dockerfile 的 EXPOSE 端口一致吗？\n□ docker-compose 的 ports 映射正确吗？\n□ COPY 的源路径和目标路径都对吗？\n□ start.sh 中启动命令正确吗？\n```\n\n**⚠️ 如果任何一个问题回答不上来，说明设计不够清晰，需要返回阶段 3 补充**\n",
"required": true
},
{
"id": "10",
"name": "成品输出",
"order": 9,
"output": "最终文件结构",
"prompt": "删除额外的测试文件，并输出：\n```\n✅ 题目生成完成！\noutput/{timestamp}_{题目名称}/\n├── docker/\n│ ├── docker-compose.yml\n│ └── web/\n│ ├── Dockerfile\n│ ├── files/\n│ └── src/\n├── exp.py\n└── writeup.md\n```\n",
"required": true
}
]
},
"困难": {
"rules": {
"depth_range": [
6,
10
],
"diff_rate": 0.5,
"max_count": 5,
"writeup_count": 10
},
"stages": [
{
"fixed_position": true,
"id": "1",
"name": "用户输入需求",
"order": 0,
"output": "语言、漏洞、场景、难度",
"prompt": "\n**必需参数**：\n\n- 语言：（如 Python、PHP、Node.js）\n- 漏洞：（如 SSTI、SQL注入、反序列化）\n- 场景：（如 OA系统、博客、电商）\n- 难度：（入门/简单/中等/困难）\n\n**示例**：\n\n```\n语言：Python\n漏洞：逻辑漏洞\n场景：OA系统\n难度：中等\n```\n\n**⚠️ 额外要求处理规则**：\n- 如果用户提供了额外要求，必须在题目设计时充分考虑并融入\n- 额外要求的优先级高于默认设计方案\n- 在设计阶段需要明确说明如何满足用户的额外要求\n\n**⚠️ 重要提醒**：在开始任何工作之前，请记住：\n\n- 所有生成的文件必须保存到 `output/{YYYYMMDD_HHMMSS}_{题目名称}/` 目录\n- 在代码生成开始前，必须先创建输出目录\n",
"required": true,
"system_stage": true
},
{
"condition": "knowledge_count > 1",
"id": "2",
"name": "漏洞主次分类",
"order": 1,
"output": "主漏洞/辅助漏洞分配",
"prompt": "\n**在获取学习材料之前，必须对用户选择的漏洞进行主次分类**。\n\n### 🎯 分类目的\n\n确保 AI 有足够的学习材料来深入理解核心漏洞，避免因漏洞过多导致每个漏洞的 writeup 数量不足。\n\n### 📊 分类规则\n\n根据以下标准将用户选择的漏洞分为**主漏洞**和**辅助漏洞**：\n\n**主漏洞**（1-2 个）：\n- 题目的核心考点，利用链的关键步骤\n- 通常是高深度漏洞（如 SSTI、反序列化、原型链污染、SQL注入、命令注入）\n- 需要深入理解才能利用的漏洞\n\n**辅助漏洞**（0-3 个）：\n- 用于信息收集、权限提升或辅助利用\n- 通常是中低深度漏洞（如路径穿越、文件包含、JWT安全、类型混淆、信息泄露）\n- 作为利用链的前置或后置步骤\n\n### 📝 分类输出格式\n\n```markdown\n### 漏洞主次分类\n\n**用户选择的漏洞**：SSTI模板注入、JWT安全、路径穿越\n\n**分类结果**：\n| 漏洞 | 分类 | 理由 |\n|------|------|------|\n| SSTI模板注入 | 主漏洞 | 高深度漏洞，需要理解模板引擎和沙箱绕过，适合作为核心考点 |\n| JWT安全 | 辅助漏洞 | 用于认证绕过，作为获取权限的前置步骤 |\n| 路径穿越 | 辅助漏洞 | 用于信息收集，获取配置文件或密钥 |\n\n**writeup 分配**：\n- 主漏洞（SSTI模板注入）：6 篇（60%）\n- 辅助漏洞（JWT安全）：2 篇（20%）\n- 辅助漏洞（路径穿越）：2 篇（20%）\n```\n\n### ⚠️ 特殊情况处理\n\n1. **只有 1 个漏洞**：该漏洞自动作为主漏洞，分配全部 writeup\n2. **所有漏洞都是高深度**：选择与场景最契合的作为主漏洞\n3. **所有漏洞都是辅助性质**：选择深度最高的作为主漏洞\n\n",
"required": false
},
{
"description": "根据用户输入和配置的脚本，从知识库中筛选并获取相关的知识点和 Writeup",
"id": "3",
"knowledge_script_code": "",
"knowledge_script_instruction": "",
"knowledge_script_name": "",
"knowledge_script_path": "",
"name": "知识库获取",
"order": 2,
"output_format": "json",
"prompt": "### 3.1 获取学习材料（必须使用 choice.py）\n```bash\npython3 data/scripts/choice.py --difficulty=<难度> --count=<数量> \"漏洞名称1\" \"漏洞名称2\"\n```\n\n**⚠️ 漏洞名称必须使用用户输入的完整名称，禁止简化或缩写！**\n- ✅ 正确：`\"SSTI模板注入\"` `\"SQL注入\"` `\"文件上传漏洞\"`\n- ❌ 错误：`\"SSTI\"` `\"SQL\"` `\"文件上传\"`\n\n**示例**：\n```bash\npython3 data/scripts/choice.py --difficulty=简单 --count=3 \"SQL注入\"\npython3 data/scripts/choice.py --difficulty=简单 --count=2 \"信息泄露\"\npython3 data/scripts/choice.py --difficulty=简单 --count=5 \"SSTI模板注入\" \"SQL注入\"\n```\n\n**choice.py 会输出选中的 writeup 文件名，然后使用 Read 工具读取 `data/writeups` 目录下对应的 .md 文件**\n\n\n### 🔍 1.2 深度学习与分析\n\n**随机阅读其中的10篇** writeup(若 writeup 不完整/不清晰，使用互联网搜索补充)。\n\n💡 **提示**：`choice.py` 会根据难度自动选出10篇writeup，你需要全部阅读这10篇writeup。\n\n重点关注：\n\n#### (1) 利用链拆解\n\n- 完整路径：入口 → FLAG\n- 关键节点：步骤类型、技术点\n- 依赖关系：前置条件\n- 深度评分：1-10 分\n\n#### (2) 核心知识提取\n\n**这是最重要的环节，必须深度挖掘**：\n\n##### a) 选手的困难点（题目深度的体现）\n\n- 记录 writeup 中的\"卡住的地方\"、\"尝试了很久\"、\"最后发现\"\n- 示例：\"尝试了各种 SQL 注入 payload 都失败，最后发现需要利用 JSON 函数\"\n\n##### b) 关键的灵光一现（\"啊哈时刻\"）\n\n- 需要特殊知识或经验才能想到的技巧\n- 示例：\"突然想到可以利用 XXX 特性\"、\"查阅文档后发现 XXX\"\n\n##### c) 技术深度体现\n\n- 需要理解底层原理的地方\n- 需要查阅文档或源码的地方\n- 示例：\"需要理解 PHP 序列化格式\"、\"需要分析 GD 库的处理流程\"\n\n##### d) 巧妙的设计\n\n- 误导性设计（诱饵路径）\n- 隐藏的关联性\n- 非直观的利用方式\n\n##### e) 非预期解法\n\n- 分析为什么会出现非预期\n- 学习如何防止类似问题\n\n#### (3) 技术组合模式\n\n- 组合类型：串行链/并行验证/状态机转换\n- 防护-绕过对：记录防护机制及绕过技巧\n- 创新点识别：⭐⭐⭐ 高度创新 / ⭐⭐ 中度创新 / ⭐ 常见技巧\n\n#### (4) 场景与业务逻辑\n\n- 真实场景还原度（1-10 分）\n- 误导设计技巧\n- 状态管理方式\n\n---\n\n### 📊 1.3 学习成果输出\n\n输出以下内容：\n\n```markdown\n## Writeup 分析报告 #N\n\n### 利用链拆解\n| 步骤 | 类型 | 技术点 | 输入 | 输出 | 依赖 | 深度 |\n|------|------|--------|------|------|------|------|\n| Step 1 | 信息收集 | 目录遍历 | URL | 配置文件 | 无 | 2/10 |\n| Step 2 | 防护绕过 | WAF绕过 | 配置文件 | payload | Step 1 | 5/10 |\n\n### 深度亮点分析 ⭐（最重要）\n1. **困难点**：选手卡住的地方（体现题目深度）\n2. **啊哈时刻**：需要灵光一现的技巧\n3. **技术深度**：需要理解底层原理的地方\n4. **巧妙设计**：误导路径、隐藏关联、非直观利用\n5. **非预期解**：为什么出现、如何防止\n\n### 创新点提取\n1. ⭐⭐⭐ [高度创新] xxx\n2. ⭐⭐ [中度创新] xxx\n\n### 可借鉴设计模式\n- 模式1：xxx（适用场景：xxx）\n```\n\n---\n\n### 📋 1.4 学习成果自检\n\n在进入下一阶段前，确认并输出：\n\n- [ ] 已分析至少 **80%** 的有效 writeup\n- [ ] 至少提取了 **10 个**可借鉴的设计模式\n- [ ] 至少发现了 **5 个**创新组合灵感\n- [ ] 对目标漏洞的深度理解达到 **8/10** 以上\n- [ ] 已掌握至少 **3 种**该漏洞的不同利用方式\n- [ ] 已了解至少 **5 种**防护-绕过对\n\n**若未达标 → 继续学习**\n\n---\n",
"required": true,
"system_prompt": "根据用户输入的需求，使用配置的知识库筛选脚本，从知识库中获取相关的知识点和 Writeup 文件。",
"system_stage": true,
"user_extension": ""
},
{
"id": "4",
"name": "知识模块化与映射",
"order": 3,
"output": "知识模块库、知识组合方案",
"prompt": "### 4.1 知识模块提取\n\n**从学习阶段提取可复用的知识模块**：\n\n```markdown\n## 知识模块库\n\n| 模块ID | 技术点 | 适用场景 | 前置条件 | 输出结果 | 深度 | 可组合性 | 来源 |\n|--------|--------|---------|---------|---------|------|---------|------|\n| KB-001 | 配置文件读取 | 任何Web应用 | 路径遍历 | 敏感配置 | 3/10 | 高 | WP#3 |\n| KB-002 | JWT密钥泄露利用 | 使用JWT的应用 | 已知密钥 | 伪造token | 5/10 | 中 | WP#3 |\n| KB-003 | SSTI沙箱绕过 | Python模板引擎 | SSTI触发点 | RCE | 8/10 | 中 | WP#7 |\n| KB-004 | 审批流程状态机绕过 | OA/工单系统 | 状态转换点 | 越权操作 | 7/10 | 中 | - |\n| KB-005 | 优惠券/积分逻辑漏洞 | 电商/营销系统 | 业务逻辑 | 金额篡改 | 6/10 | 高 | - |\n| ... | ... | ... | ... | ... | ... | ... | ... |\n```\n\n**要求**：\n\n- 至少提取 **15 个**独立的知识模块\n- 每个模块有清晰的\"输入-处理-输出\"定义\n- 标注深度评分和可组合性\n\n### 4.2 知识组合矩阵\n\n**识别可组合的知识模块**：\n\n```markdown\n## 知识组合方案\n\n| 组合ID | 模块1 | 模块2 | 组合方式 | 创新度 | 难度提升 | 适用场景 | 来源 |\n|--------|-------|-------|---------|--------|---------|---------|------|\n| COMB-001 | KB-001 | KB-002 | 串行 | ⭐⭐⭐ | +3 | 认证绕过 | WP#3 |\n| COMB-002 | KB-005 | KB-008 | 并行 | ⭐⭐ | +2 | 权限提升 | WP#7+WP#12 |\n| ... | ... | ... | ... | ... | ... | ... | ... |\n```\n\n**要求**：\n\n- 至少识别 **8 个**可行的知识组合\n- 标注创新度和难度提升\n\n### 4.3 需求-知识映射\n\n**根据用户需求，从知识库中筛选匹配的模块**：\n\n```markdown\n## 需求-知识匹配报告\n\n### 用户需求\n- 语言：Python\n- 漏洞：SSTI、逻辑漏洞\n- 场景：OA系统\n- 难度：困难\n\n### 匹配的知识模块（按优先级排序）\n| 模块ID | 匹配度 | 适用性分析 | 计划使用方式 |\n|--------|--------|-----------|-------------|\n| KB-003 | 95% | SSTI沙箱绕过，完全匹配 | 作为主漏洞的核心利用 |\n| KB-008 | 85% | 权限验证逻辑漏洞 | 作为前置步骤 |\n| KB-001 | 80% | 配置文件泄露 | 作为信息收集步骤 |\n| ... | ... | ... | ... |\n\n### 选中的知识组合\n| 组合ID | 适用性 | 创新潜力 | 计划应用 |\n|--------|--------|---------|---------|\n| COMB-005 | 高 | ⭐⭐⭐ | 作为Step 2-4的核心链路 |\n| COMB-012 | 中 | ⭐⭐ | 作为备选方案 |\n\n### 知识迁移计划\n针对每个选中的知识模块，说明如何迁移到新场景：\n\n**KB-003 迁移计划**：\n- 原场景：博客系统的模板渲染\n- 新场景：OA系统的报表生成\n- 迁移调整：\n1. 触发点从\"文章模板\"改为\"报表模板\"\n2. 增加权限检查（OA系统特有）\n3. 沙箱限制从Jinja2改为自定义沙箱\n- 预期难度变化：+2（因为增加了权限层）\n- 创新点：结合OA审批流程的状态机\n```\n\n**检查点**：\n\n- [ ] 至少选择了 **5 个**知识模块用于设计\n- [ ] 至少选择了 **2 个**知识组合\n- [ ] 每个模块都有明确的迁移计划\n- [ ] 知识覆盖了利用链的 **80%** 以上步骤\n",
"required": true
},
{
"id": "5",
"name": "题目设计",
"order": 4,
"output": "利用链、核心代码预写",
"prompt": "\n### 🎨 5.1 设计目标\n\n**核心原则**：\n\n1. **知识应用优先**：每个步骤必须追溯到学习的知识模块\n\n2. **差异化创新**：与学习材料的差异度要求\n- 中等题：≥50%\n- 困难题：≥70%\n\n3. **深度保证**：满足阶段 5.7 的深度标准\n\n4. **趣味性保证**：包含\"啊哈时刻\"和渐进式发现\n\n5. **源码提供决策** ：根据题目特性决定是否提供源码\n\n---\n\n### 🎯 5.2 场景攻击面分析（必须）\n\n**在设计利用链之前，必须深入分析场景的业务特有攻击面**：\n\n#### 1. 核心业务流程分析\n\n列出场景的 3-5 个核心业务流程，例如：\n- **OA系统**：登录 → 发起申请 → 审批 → 归档 → 查询\n- **电商系统**：浏览 → 加购 → 下单 → 支付 → 发货 → 评价\n- **论坛系统**：注册 → 发帖 → 评论 → 私信 → 举报\n- **医疗系统**：预约 → 挂号 → 就诊 → 处方 → 缴费\n\n#### 2. 状态转换点识别\n\n识别业务流程中的关键状态变化：\n- 待审批 → 已审批（审批流程）\n- 未支付 → 已支付（支付流程）\n- 草稿 → 已发布（内容发布）\n- 待处理 → 已完成（工单流程）\n\n#### 3. 权限边界分析\n\n识别不同角色的权限差异：\n- 普通用户 vs 管理员\n- 申请人 vs 审批人\n- 买家 vs 卖家\n- 患者 vs 医生\n\n#### 4. 数据敏感点识别\n\n识别敏感数据的存储和流动路径：\n- 认证凭据（密码、密钥、token）\n- 业务数据（订单、金额、积分）\n- 个人信息（身份、联系方式）\n\n**⚠️ 强制要求**：至少 **1 个利用步骤**必须针对上述分析中的**场景特有点**，而非通用漏洞（如通用的登录SSTI、搜索SQL注入）\n\n---\n\n### 🔀 5.3 多路径设计（必须）\n\n**在确定最终利用链之前，必须设计多种方案并对比选择**：\n\n#### 步骤 1：列出至少 2 种完全不同的利用链方案\n\n每种方案使用**不同的核心漏洞入口**或**不同的利用路径**。\n\n#### 步骤 2：对比评估\n\n| 维度 | 方案 A | 方案 B |\n|------|--------|--------|\n| 场景融合度 | 漏洞与业务逻辑的结合程度 | |\n| 创新度 | 技术组合的新颖程度 | |\n| 趣味性 | 解题过程的探索感 | |\n| 可实现性 | 技术实现的可行性 | |\n\n#### 步骤 3：选择最终方案\n\n**选择标准（按优先级）**：\n1. **场景融合度最高**：漏洞与业务逻辑深度绑定\n2. **创新度最高**：避免常见的利用模式\n3. **趣味性最高**：有\"啊哈时刻\"和探索感\n\n**⚠️ 禁止**：只设计一种方案直接使用\n\n---\n\n### 📊 5.4 利用链模式参考\n\n**避免总是使用相同的利用链模式，参考以下多种模式**：\n\n**模式 A：信息泄露链**\n```\n信息收集 → 敏感信息获取 → 认证绕过 → 目标达成\n```\n\n**模式 B：业务逻辑链**（推荐优先考虑）\n```\n功能探索 → 业务流程分析 → 状态机漏洞/逻辑漏洞 → 权限提升\n```\n\n**模式 C：多点组合链**\n```\n漏洞点 A（低危）+ 漏洞点 B（低危）→ 组合利用 → 高危影响\n```\n\n**模式 D：时序/竞态链**\n```\n正常流程 → 时序分析 → 竞态条件 → 状态篡改\n```\n\n**模式 E：二次触发链**\n```\n数据写入 → 存储 → 二次读取触发 → 漏洞利用\n```\n\n**模式 F：信任边界链**\n```\n低权限入口 → 信任传递 → 高权限上下文 → 目标达成\n```\n\n---\n\n### 📈 5.5 深度评估示例\n\n---\n\n#### 深度 5/10 - 合格步骤（中等题最低要求）\n\n- **SQL 注入绕过黑名单**：需要使用大小写混合 + 注释符绕过关键词过滤\n- **Cookie 伪造**：需要通过 SQL 注入获取 Secret，然后理解 HMAC 签名机制\n- **文件上传绕过**：需要绕过 MIME 类型检查 + 文件扩展名检查（双重防护）\n- **权限提升**：需要理解业务逻辑，利用状态机漏洞\n\n**为什么深度合格**：\n\n- 需要绕过 2 层以上防护\n- 需要理解一定的技术原理\n- 需要组合多个技巧\n\n---\n\n#### 深度 7/10 - 高深度步骤（困难题要求）\n\n- **INSERT SQL 注入**：需要理解 SQL 语法，使用双重编码绕过 `html_entity_decode`\n- **Phar 反序列化**：需要理解 PHP 反序列化机制，构造 Phar 文件，绕过图片检测\n- **竞态条件利用**：需要理解多线程、时序问题，精确控制请求时间\n- **JWT 算法混淆**：需要理解 JWT 结构，利用 `alg: none` 或 RS256→HS256 转换\n\n**为什么深度高**：\n\n- 需要深入理解底层原理\n- 需要组合 3 种以上技术\n- 需要精确控制利用过程\n- 有\"啊哈时刻\"（需要灵光一现）\n\n---\n\n#### 深度 9/10 - 极高深度步骤（困难题的核心步骤）\n\n- **复杂魔术方法链**：需要构造 5 层以上的魔术方法调用链，理解 PHP 对象交互\n- **二次注入 + 时序竞态**：需要先通过注入写入恶意数据，然后利用竞态条件触发\n- **类型混淆 + 反序列化**：需要理解 PHP 类型比较机制，构造特殊对象绕过检查\n- **多系统交互利用**：需要同时利用 Web + Redis + MySQL 的特性组合攻击\n\n**为什么深度极高**：\n\n- 需要非常深入的底层理解\n- 需要创新性的利用方式\n- 需要多个\"啊哈时刻\"\n- 需要查阅文档或源码才能想到\n\n---\n\n#### ⚠️ 常见的\"假深度\"步骤（需要避免）\n\n1. **简单的编码绕过**\n- ❌ 错误：只需要 URL 编码一次就能绕过\n- ✅ 正确：需要多层编码 + 理解解码顺序\n\n2. **弱密码爆破**\n- ❌ 错误：密码是 `admin123`，字典前 100 个就能爆破\n- ✅ 正确：密码需要通过其他漏洞获取，或者是强密码但有提示\n\n3. **直接信息泄露**\n- ❌ 错误：Secret 直接写在配置文件中，通过目录遍历就能读取\n- ✅ 正确：Secret 需要通过 SQL 注入 + 理解表结构才能获取\n\n4. **单一防护绕过**\n- ❌ 错误：只有一个黑名单，绕过后就能利用\n- ✅ 正确：有多层防护，需要逐层绕过\n\n---\n\n### 🔍 5.6 源码提供决策\n\n**在设计题目时，必须明确决定是否提供源码，并确保难度合理**：\n\n#### 决策标准\n\n**必须提供源码的情况**：\n\n- 题目核心考点是代码审计\n- 漏洞点隐藏在复杂的业务逻辑中，黑盒测试难以发现\n- 需要理解底层实现才能构造payload\n\n**可以不提供源码的情况**：\n\n- 题目核心考点是黑盒渗透\n- 漏洞点可以通过功能测试发现\n- 防护机制可以通过试错推断\n- 提供源码会降低难度过多\n\n---\n\n### 🎯 5.7 深度与趣味性设计标准\n\n#### 深度评分标准\n\n| 难度 | 平均深度 | 最高深度 | **最低深度** | 高深度步骤数 | 防护层数 | 趣味性要求 |\n| ---- | -------- | -------- | ------------ | ------------ | -------- | ----------------------------------------- |\n| 中等 | ≥6.0 | ≥8.0 | **≥5.0** | ≥2步≥7.0 | 4-5层 | 2个啊哈时刻 + 1个创新组合 + 1个误导设计 |\n| 困难 | ≥7.5 | ≥9.0 | **≥6.0** | ≥3步≥8.0 | 6+层 | 2个啊哈时刻 + 2个创新组合 + 2个误导设计 |\n\n**🚨 重要**：中等/困难题 **不允许有简单步骤**（深度 <5.0），每一步都必须有深度！\n\n#### ❌ 禁止的表面化设计（中等/困难题）\n\n1. **简单字符串替换绕过** → ✅ 改进：多层递归过滤 + 语义分析\n2. **单一大小写绕过** → ✅ 改进：协议白名单 + 路径规范化\n3. **单点防护机制** → ✅ 改进：多层级独立验证 + 状态关联检查\n4. **直接信息泄露** → ✅ 改进：需要通过漏洞获取信息\n5. **明文注释漏洞点** → ✅ 改进：代码逻辑自然，不显示漏洞提示\n\n#### ✅ 深度设计要素\n\n**中等题**：**每个步骤**满足至少 2 项\n\n- 多重防护组合（≥2 种绕过技术）\n- 上下文依赖利用（理解业务逻辑/框架特性）\n- 状态关联验证（需要前置步骤的特定状态）\n- 深层技术理解（底层原理）\n\n**困难题**：**每个步骤**满足至少 3 项，且包含：\n\n- 非预期路径封堵（≥3 个诱饵路径）\n- 时序与竞态利用\n- 多系统交互\n- 创新组合利用\n\n#### 🎨 趣味性设计技巧\n\n1. **\"啊哈时刻\"**：关键步骤需要灵光一现\n2. **渐进式发现**：每步揭示新信息，避免一次性暴露\n3. **真实场景模拟**：基于真实业务逻辑（OA审批、电商订单、权限管理）\n4. **隐藏的关联性**：表面独立，实际存在隐藏交互\n5. **误导性设计**：诱饵路径（看似可行但不通）\n\n---\n\n### 📝 5.8 设计输出格式\n\n```markdown\n## 题目设计方案\n\n### 基本信息\n- 题目名称：xxx\n- 难度：中等\n- 预计解题时间：2-3 小时\n- 差异度：55%（相比 WP#3、WP#7）\n\n### 源码提供决策\n- **是否提供源码**：是/否\n- **决策理由**：xxx\n- **难度影响**：xxx\n- **平衡措施**：xxx\n\n### 利用链设计\n| 步骤 | 类型 | 技术点 | 深度 | 知识来源 | 创新点 | 防护机制 | 绕过方式 |\n|------|------|--------|------|---------|--------|---------|---------|\n| Step 1 | 信息收集 | 配置泄露 | 3/10 | KB-001 | 改为OA场景 | 路径白名单 | 路径规范化绕过 |\n| Step 2 | 认证绕过 | JWT伪造 | 5/10 | KB-002 | 增加时间戳验证 | 签名验证 | 密钥泄露+时间戳预测 |\n| Step 3 | 权限提升 | 逻辑漏洞 | 7/10 | KB-008 | 结合审批流程 | 状态机验证 | 状态竞态 |\n| Step 4 | 代码执行 | SSTI | 9/10 | KB-003+COMB-005 | 自定义沙箱 | 黑名单过滤 | 多层编码+属性链 |\n\n**平均深度**：6.0/10 ✅\n**最高深度**：9.0/10 ✅\n**最低深度**：3/10 ❌（简单题可接受，中等/困难题不合格）\n**高深度步骤数**：2 步 ≥7.0 ✅\n\n**深度说明**（必须填写）：\n- **Step 1 (3/10)**：为什么是 3/10？因为只需要简单的路径遍历，无需深入理解\n- **Step 2 (5/10)**：为什么是 5/10？因为需要理解 HMAC 签名机制 + 通过 SQL 注入获取密钥（2层技术）\n- **Step 3 (7/10)**：为什么是 7/10？因为需要理解状态机 + 竞态条件 + 业务逻辑（3层技术 + 啊哈时刻）\n- **Step 4 (9/10)**：为什么是 9/10？因为需要构造复杂的沙箱绕过 + 多层编码 + 属性链（4层技术 + 需要查阅文档）\n\n### 知识应用追踪\n- **直接应用**：KB-001, KB-002, KB-003, KB-008（4个）\n- **组合应用**：COMB-005（1个）\n- **创新扩展**：Step 3 的状态竞态（基于 KB-008 创新）\n- **知识应用率**：100%（所有步骤都有知识来源）\n- **差异度分析**：\n- Step 1：30%（场景迁移）\n- Step 2：50%（增加时间戳验证）\n- Step 3：80%（创新的状态竞态）\n- Step 4：60%（自定义沙箱）\n- **总体差异度**：55% ✅\n\n### 深度亮点设计 ⭐\n1. **啊哈时刻 #1**：发现审批流程的状态竞态（Step 3）\n2. **啊哈时刻 #2**：理解自定义沙箱的属性链绕过（Step 4）\n3. **误导设计**：诱饵路径 - 看似可用的 SQL 注入点（实际无法利用）\n4. **隐藏关联**：Step 1 的配置文件包含 Step 2 的密钥提示\n\n### 场景设计\n- 系统类型：OA审批系统\n- 核心功能：报表生成、审批流程\n- 辅助功能：xxx、xxx\n- 无用功能（与漏洞无关，仅为了使系统更加真实或者迷惑选手）：xxx、xxx\n- 真实度：8/10\n- 误导元素：假的管理员登录入口、无用的 API 文档\n\n### 非预期解防护\n1. **防护点 #1**：禁止直接访问 /flag.txt（权限检查）\n2. **防护点 #2**：SSTI 黑名单包含常见 bypass（需要深度理解）\n3. **防护点 #3**：审批流程的状态验证（防止跳步）\n```\n\n### 🔬 5.9 设计可实现性验证\n\n**在进入代码生成前，必须验证设计在技术上可实现：**\n\n#### 验证维度：\n\n**1. 利用链完整性检查**\n\n- [ ] 每一步的输入来源明确（用户输入/前一步输出/题目提供）\n- [ ] 每一步的输出能被下一步使用\n- [ ] 没有循环依赖（需要A获得B，需要B获得A）\n- [ ] 没有信息黑洞（需要的信息无法获得）\n\n**2. 技术栈兼容性检查**\n\n- [ ] 选择的语言/框架支持设计的漏洞利用方式\n- [ ] 防护机制不会完全阻断利用链\n- [ ] 编码/特殊字符处理不会破坏payload\n\n**3. 状态管理可行性**\n\n- [ ] Session/Cookie/Token的传递路径清晰\n- [ ] 多步骤攻击的状态能正确保持\n- [ ] 时序依赖（如竞态条件）在实现上可控\n\n**4. 数据流模拟**\n\n绘制完整的数据流图：\n[用户输入] → [处理函数A] → [中间状态] → [处理函数B] → [漏洞触发] → [FLAG]\n↓ ↓ ↓ ↓ ↓\npayload1 过滤/验证 session存储 权限检查 文件读取\n\n**检查每个箭头：**\n\n- 数据格式是否兼容？\n- 是否有隐式转换？\n- 是否有中间过滤？\n\n**5. 伪代码验证**\n\n为每个关键步骤写伪代码：\n\n```\n# Step 1: 信息收集\ninput: URL参数 ?file=xxx\nprocess: 路径拼接 /var/www/ + file\noutput: 文件内容\ncheck: ✅ 能否读取到敏感文件？\n\n# Step 2: 权限绕过\ninput: 从Step1获得的密钥\nprocess: JWT伪造\noutput: admin token\ncheck: ✅ 密钥格式是否正确？✅ JWT库是否支持？\n\n# Step 3: RCE\ninput: admin token\nprocess: 模板渲染\noutput: 命令执行\ncheck: ✅ 模板引擎是否支持？✅ 沙箱能否绕过？\n```\n\n**6. 常见陷阱检查**\n\n| 陷阱类型 | 检查项 | 示例 |\n| -------- | ---------------------------------- | --------------------------------- |\n| 字符转义 | payload中的特殊字符是否会被转义？ | SQL注入中的单引号、SSTI中的花括号 |\n| 编码问题 | 多层编码/解码是否会破坏payload？ | URL编码、Base64、Unicode |\n| 类型转换 | 弱类型语言的隐式转换是否影响利用？ | PHP的 `==` vs `===` |\n| 长度限制 | payload是否超过字段长度限制？ | 数据库字段、HTTP header |\n| 时序问题 | 多步骤攻击的时序是否可控？ | Session过期、Token时效 |\n| 环境依赖 | 是否依赖特定的库版本/配置？ | Python2 vs Python3 |\n\n**7. 🆕 关键实现细节预写（必须）**\n\n**在设计阶段就必须明确以下技术细节，不能留到代码生成阶段：**\n\n```markdown\n### 关键实现细节\n\n1. **漏洞触发点**\n- 具体使用什么函数/方法触发漏洞？\n- 输入参数的格式是什么？（JSON/Form/Cookie/Header）\n- 输出期望是什么？\n\n2. **核心代码片段**（5-10行伪代码）\n- 展示漏洞如何被触发\n- 如果写不出来，说明设计不可行，需要调整\n\n3. **exp 核心逻辑**（5-10行伪代码）\n- 展示如何构造请求和 payload\n- 确认利用链每一步的数据格式\n\n4. **潜在冲突检查**\n- 模板文件中是否会包含与模板语法冲突的内容？\n- 配置文件中是否有特殊字符需要转义？\n- 多个组件之间是否有冲突？\n```\n\n**8. 🆕 漏洞代码正确性验证（必须）**\n\n**必须明确区分\"安全写法\"和\"漏洞写法\"，避免生成无法触发的漏洞代码：**\n\n```markdown\n### 漏洞代码正确性验证\n\n对于每个漏洞触发点，必须写出：\n\n1. **❌ 安全写法**（不能触发漏洞的写法）\n- 示例：render_template_string(template, user_input=data)\n- 原因：用户输入作为变量传递，不会被解析执行\n\n2. **✅ 漏洞写法**（能触发漏洞的写法）\n- 示例：render_template_string(f'{data}
')\n- 原因：用户输入直接拼接到模板字符串中，会被解析执行\n\n3. **验证问题**\n- 我设计的代码是哪种写法？\n- 如果是安全写法，如何修改为漏洞写法？\n```\n\n**9. 🆕 exp 执行流程预演（必须）**\n\n**在写 exp 代码前，必须模拟完整的攻击流程：**\n\n```markdown\n### exp 执行流程预演\n\n1. **攻击者身份**\n- 需要什么权限？（匿名/普通用户/admin）\n- 如何获取该权限？（注册/已知密码/漏洞提权）\n\n2. **请求序列**（按顺序列出每个请求）\n| 步骤 | 请求方法 | 路径 | 参数 | 期望响应 |\n|------|---------|------|------|---------|\n| 1 | POST | /login | username=xxx | 302 + cookie |\n| 2 | POST | /vuln | payload=xxx | 200 + 泄露数据 |\n| ... | ... | ... | ... | ... |\n\n3. **flag 回显路径**（必须明确）\n- RCE 执行后，flag 如何传递给攻击者？\n- 选项：HTTP响应 / 文件读取 / DNS外带 / 时间盲注\n- 如果选择文件读取，如何再次读取该文件？\n\n4. **潜在失败点**\n- 哪些步骤可能失败？\n- 失败后如何检测和恢复？\n```\n\n**⚠️ 如果无法写出关键代码片段，必须简化设计或更换技术方案**\n\n**验证输出格式：**\n\n```\n## 可实现性验证报告\n\n### 利用链完整性：✅ 通过\n- Step 1→2：通过文件读取获得密钥 ✅\n- Step 2→3：使用密钥伪造token ✅\n- Step 3→FLAG：使用token访问admin接口 ✅\n\n### 技术栈兼容性：✅ 通过\n- Python Flask支持SSTI ✅\n- Jinja2模板引擎可利用 ✅\n\n### 潜在问题：⚠️ 1个\n- 问题1：密钥可能包含特殊字符，需要处理\n- 解决方案：使用Base64编码存储\n\n### 数据流图：\n[已绘制，见上方]\n\n### 伪代码验证：✅ 通过\n[已完成，见上方]\n\n### 结论：✅ 设计可实现，可以进入代码生成阶段\n```\n\n**若验证失败 → 返回5.8重新设计利用链**\n\n---\n\n\n",
"required": true
},
{
"id": "6",
"name": "质量检查与优化",
"order": 5,
"output": "验证清单",
"prompt": "\n### ✅ 6.1 检查清单（优先级排序）\n\n#### 🚫 一票否决项（必须通过）\n\n1. **知识应用度检查**\n- [ ] 所有步骤都有明确的知识来源（KB-XXX 或 COMB-XXX）\n- [ ] 知识应用率 ≥80%\n- [ ] 差异度达标（简单≥30%，中等≥50%，困难≥70%）\n\n2. **源码提供决策检查**\n- [ ] 已明确决定是否提供源码\n- [ ] 决策理由充分（符合决策标准）\n- [ ] 难度平衡措施到位\n- [ ] 如果不提供源码：黑盒可测\n\n3. **深度达标检查**\n- [ ] 平均深度达标（中等≥6.0，困难≥7.5）\n- [ ] 最高深度达标（中等≥8.0，困难≥9.0）\n- [ ] **最低深度达标**（中等≥5.0，困难≥6.0）\n- [ ] 高深度步骤数达标\n- [ ] **中等/困难题无简单步骤**（所有步骤深度≥5.0）\n- [ ] **逐步检查每个步骤的深度**：列出每个步骤的深度评分，确保无遗漏\n\n4. **趣味性检查**\n- [ ] 包含至少 1 个\"啊哈时刻\"\n- [ ] 有渐进式发现（不是一次性暴露所有信息）\n- [ ] 有误导设计或隐藏关联\n\n5. **技术深度检查**\n- [ ] 中等/困难题：每个绕过点满足深度设计要素（见阶段 5.7）\n- [ ] 避免表面化设计（见阶段 5.7 禁止列表）\n\n6. **场景真实性检查**\n- [ ] 业务逻辑合理（不是为了漏洞而设计）\n\n7. **场景融合度检查**（新增）\n- [ ] 至少 1 个利用步骤针对**场景特有功能**（非通用的登录/搜索/上传）\n- [ ] 漏洞触发点与业务流程有逻辑关联\n- [ ] 已完成场景攻击面分析（阶段 5.2）\n\n8. **多样性检查**（新增）\n- [ ] 已设计并对比至少 2 种利用链方案（阶段 5.3）\n- [ ] 最终方案不是最\"常见\"的利用模式\n- [ ] 利用链模式不是简单的\"信息泄露→认证绕过→RCE\"\n\n9. **设计可实现性检查**\n- [ ] 利用链没有循环依赖\n- [ ] 所有需要的信息都能获得\n- [ ] 技术栈支持设计的利用方式\n- [ ] 已完成数据流模拟\n- [ ] 已完成伪代码验证\n- [ ] 已识别并解决潜在陷阱（字符转义、编码、类型转换等）\n\n#### 🆕 6.2 实现风险评估（必须通过）\n\n**在进入代码生成前，评估设计的实现风险：**\n\n| 风险类型 | 检查项 | 状态 |\n|---------|-------|------|\n| **技术复杂度** | 设计中是否有过于复杂的技术点？能否简化？ | |\n| **依赖风险** | 是否依赖特定版本的库/框架？版本兼容性如何？ | |\n| **环境差异** | 本地开发环境和 Docker 容器环境是否一致？ | |\n| **组件冲突** | 多个组件/功能之间是否可能冲突？ | |\n| **文件内容冲突** | 生成的文件内容是否会与框架语法冲突？ | |\n\n**⚠️ 如果风险过高（超过 2 项高风险），应该简化设计**\n\n10. **用户漏洞覆盖检查**（一票否决）\n- [ ] 用户要求的**所有漏洞类型**都在利用链中被使用\n- [ ] 每个漏洞类型在利用链中有**明确的步骤编号**\n- [ ] 如果某个漏洞类型无法使用，必须**明确说明原因**并获得用户确认\n- **验证格式**：\n```\n用户要求漏洞: [SSTI, SSRF, PHP反序列化]\n- SSTI: Step 3 ✅\n- SSRF: Step 2 ✅\n- PHP反序列化: Step 4 ✅\n覆盖率: 3/3 = 100% ✅\n```\n\n---\n\n### 📈 6.3 如何提升步骤深度（修复指南）\n\n**当发现某个步骤深度不够时，使用以下方法提升**：\n\n#### 方法 1：增加防护层数\n\n**原版**（深度 3/10）：\n\n- SQL 注入：直接 `' OR 1=1--` 就能绕过\n\n**提升后**（深度 5/10）：\n\n- 增加关键词黑名单：需要使用大小写混合绕过\n- 增加注释符过滤：需要使用 `/**/` 绕过\n- 增加长度限制：需要精简 payload\n\n**提升后**（深度 7/10）：\n\n- 再增加 WAF 规则：需要使用编码绕过\n- 再增加语义分析：需要理解 SQL 解析顺序\n- 再增加时间延迟检测：需要使用盲注技巧\n\n---\n\n#### 方法 2：增加前置依赖\n\n**原版**（深度 4/10）：\n\n- Cookie 伪造：Secret 直接写在配置文件中，通过目录遍历就能读取\n\n**提升后**（深度 6/10）：\n\n- Secret 存储在数据库中：需要先通过 SQL 注入获取\n- Secret 需要解密：需要理解加密算法\n- Secret 有时间戳验证：需要预测或同步时间\n\n---\n\n#### 方法 3：增加技术组合\n\n**原版**（深度 5/10）：\n\n- 文件上传：绕过 MIME 类型检查即可\n\n**提升后**（深度 7/10）：\n\n- 需要绕过 MIME 类型检查\n- 需要绕过文件扩展名检查\n- 需要绕过文件内容检查（如 `getimagesize()`）\n- 需要利用 Phar 反序列化触发\n\n---\n\n#### 方法 4：增加底层理解要求\n\n**原版**（深度 4/10）：\n\n- SSTI：直接 `{{7*7}}` 就能执行\n\n**提升后**（深度 8/10）：\n\n- 有黑名单过滤：需要理解 Jinja2 语法，使用属性访问绕过\n- 有沙箱限制：需要理解 Python 对象模型，构造属性链\n- 需要查阅文档：找到可以利用的内置函数\n- 需要多层编码：绕过 WAF 检测\n\n---\n",
"required": true,
"skip_forbidden": true
},
{
"id": "7",
"name": "代码生成与验证",
"order": 6,
"output": "后端代码、Docker 文件",
"prompt": "### 7.0 代码生成前强制自检（必须执行）\n\n**在写任何代码之前，必须逐项检查以下内容**：\n\n1. **黑名单/过滤器一致性检查**：\n- 列出设计中所有的防护机制（黑名单、过滤器、WAF 等）\n- 列出设计中所有的绕过 payload\n- **逐一验证**：每个 payload 是否能通过对应的防护机制？\n- 如果 payload 会被自己设计的黑名单拦截，**必须在写代码前修改设计**\n\n2. **利用链可达性检查**：\n- 从 Step 1 到最后一步，逐步模拟数据流\n- 确认每一步的输入都能从上一步获得\n- 确认每一步的输出都能传递给下一步\n\n3. **技术栈兼容性检查**：\n- 确认使用的函数/方法在目标语言版本中存在\n- 确认使用的库/框架版本支持设计的功能\n\n**⚠️ 常见错误示例（必须避免）**：\n- ❌ 设计用 `eval()` 执行代码，但黑名单包含 `eval` → 自相矛盾\n- ❌ 设计用 `constructor` 绕过，但黑名单包含 `constructor` → 自相矛盾\n- ❌ 设计污染 `__proto__`，但 JSON 解析器过滤了 `__proto__` → 无法触发\n\n**✅ 正确做法**：\n- 如果 payload 需要用 `eval`，则黑名单不能包含 `eval`（或提供其他绕过方式）\n- 如果黑名单必须包含某关键词，则 payload 必须使用 Unicode 编码等方式绕过\n\n### 7.1 生成原则\n\n1. **完整性**：包含所有设计的功能点和漏洞点\n2. **零注释**：代码中禁止任何注释\n3. **真实性**：模拟真实业务逻辑\n4. **隐蔽性**：漏洞点自然隐藏在业务逻辑中\n\n**提供源码时**：禁止硬编码管理员密码\n**不提供源码时**：可以硬编码\n\n### 7.2 增量生成顺序（每步必须验证）\n\n**⚠️ 本阶段只生成题目代码和 Docker 文件，exp.py 和 writeup.md 在阶段 9 生成**\n\n1. **后端代码**\n- 检查：所有 import 语句是否完整\n- 检查：路由定义是否正确（路径、方法）\n- 检查：漏洞触发点是否使用\"漏洞写法\"\n\n2. **依赖文件**\n- 检查：requirements.txt 包含所有导入的模块\n- 检查：版本号是否明确指定\n\n3. **前端文件**\n- 检查：表单 action 路径与后端路由一致\n- 检查：input name 与后端参数名一致\n- 检查：模板语法不与框架冲突\n\n4. **Docker 文件**\n- 检查：EXPOSE 端口与应用监听端口一致\n- 检查：docker-compose ports 映射正确\n- 检查：COPY 路径正确\n\n**⚠️ 每步生成后立即验证，发现问题立即修复**\n\n### 7.3 文件结构\n\n```\noutput/{timestamp}_{题目名称}/\n├── docker/\n│ ├── docker-compose.yml\n│ └── web/\n│ ├── Dockerfile\n│ ├── files/ (flag.sh, start.sh)\n│ └── src/\n```\n\n**注意：exp.py 和 writeup.md 在阶段 9 生成**\n\n### 7.4 核心文件要求\n\n**docker-compose.yml**：\n- 外部端口：随机 42500-42600\n- 只允许 1 个 web 容器\n- 设置唯一 container_name\n\n**Dockerfile**：\n- 使用官方镜像\n- 包含 `ENV DASFLAG DASCTF{test12345}`\n- 优先使用国内源\n\n**flag.sh**：\n```bash\n#!/bin/bash\necho $DASFLAG > /flag.txt\nexport DASFLAG=nonono\nrm -f /flag.sh\n```\n\n### 7.5 设计-实现一致性验证\n\n生成完成后，验证：\n- [ ] 每个设计步骤都有对应的代码实现\n- [ ] 漏洞触发点使用的是\"漏洞写法\"\n- [ ] 路由路径、参数名与阶段 5 设计一致\n",
"required": true
},
{
"id": "8",
"name": "Docker 环境构建",
"order": 7,
"output": "容器验证",
"prompt": "### 8.1 Docker 构建\n\n**严格遵循 DASCTF 标准**：\n\n- docker-compose.yml：仅使用 `image`, `build`, `ports`，**禁止多容器架构**\n- Dockerfile：使用官方镜像，包含 `ENV DASFLAG DASCTF{test12345}` 和 `EXPOSE 80`\n- flag.sh：写入 FLAG，覆盖环境变量，删除自身\n- start.sh：按顺序启动服务，使用 `tail -f /dev/null`\n- Dockerfile：相关环境的安装优先使用国内源，包括apt、pip等，避免过慢\n\n**⚠️ 容器数量限制**：\n- 只允许 **1 个 web 容器**，flag 必须在 web 容器内的 `/flag.txt`\n- **禁止**：多容器架构（如 web + redis、web + mysql 分离等）\n- 如需 Redis/MySQL，必须在同一容器内启动\n\n### 8.2 分层验证流程（必须按顺序执行）\n\n**不要一次性测试所有功能！按以下顺序分层验证：**\n\n#### 第一层：容器启动验证\n```bash\n# 使用唯一项目名启动（避免与其他容器冲突）\ndocker-compose -p ctf_test up -d --build\n# 只查看当前项目的容器状态（不要用 docker ps，会看到其他项目的容器）\ndocker-compose -p ctf_test ps\n```\n**如果失败**：检查 Dockerfile、依赖安装、start.sh\n**⚠️ 重要**：必须使用 `docker-compose -p ctf_test ps` 而不是 `docker ps`，否则会误判其他项目的容器\n\n#### 第二层：服务可用性验证\n```bash\ncurl http://localhost:端口/ # 确认返回 200\n```\n**如果失败**：检查应用启动命令、端口配置\n\n#### 第三层：基础功能验证\n- 测试正常功能（如注册、登录）是否工作\n- **不涉及漏洞利用**\n**如果失败**：检查路由、数据库、Session 配置\n\n#### 第四层：漏洞触发验证\n- 使用**最简单的 payload** 测试漏洞是否可触发\n- 例如：SSTI 测试 `{{7*7}}`，SQL 注入测试 `' or 1=1--`\n**如果失败**：检查漏洞触发点代码、过滤逻辑\n\n#### 第五层：完整 exp 验证\n```bash\npython3 ../exp.py localhost 端口 DASCTF{test12345}\n```\n**如果失败**：检查 exp.py 与后端代码的一致性\n\n**⚠️ 每层验证通过后再进入下一层。失败时立即修复当前层，不要跳层。**\n\n### 8.3 测试清单(需要输出)\n\n- [ ] Docker 容器能够正常启动\n- [ ] 前端页面正常显示\n- [ ] **前端页面无测试账号、管理员账号等信息**\n- [ ] **源码注释无漏洞点、绕过方法等泄露**\n- [ ] exp.py 能够成功获取 FLAG\n- [ ] 跳步验证通过（无非预期解）\n- [ ] **信息泄露检查**\n- [ ] 前端页面无测试账号、管理员账号、敏感路径等信息\n- [ ] 前端页面无漏洞提示、FLAG路径等信息\n- [ ] 源码注释无漏洞点、绕过方法、敏感信息等泄露\n- [ ] 源码注释无解题步骤提示\n\n**若测试失败 → 修复代码并重新测试**\n",
"required": true
},
{
"id": "9",
"name": "exp 和 writeup",
"order": 8,
"output": "exp.py、writeup.md",
"prompt": "**⚠️ 只有阶段 8 测试全部通过后，才能进入本阶段**\n\n### 9.1 完善 exp.py\n\n基于阶段 5.4 的简易 exp 草稿，完善为标准格式：\n\n```python\n#!/usr/bin/python\n# -*- coding: utf-8 -*-\nimport re, sys, requests\n\nHOST, PORT, FLAG = sys.argv[1:4]\n\ndef exp(ip, port):\n# 完整 exploit 流程\nr = requests.get(f\"http://{ip}:{port}/...\")\nflag = re.findall('DASCTF{(.*?)}', r.text)[0]\nreturn flag\n\nif __name__ == '__main__':\nassert exp(HOST, PORT) == FLAG\nprint(\"Pass!\")\n```\n\n### 9.2 运行 exp.py 验证\n\n```bash\ncd output/{timestamp}_{题目名称}/\npython3 exp.py localhost 端口 test12345\n```\n\n**⚠️ 必须输出 `Pass!` 才能继续编写 writeup**\n\n如果测试失败：\n1. 检查 exp.py 的请求路径、参数名是否与后端一致\n2. 检查 payload 是否被过滤\n3. 修复后重新运行测试\n\n### 9.3 编写 writeup.md（严格按照如下格式）\n\n```markdown\n# 题目名 的解题思路\n\n## 题目信息\n| 题目名 | 题目描述 | 类型 | 预计解题时间 | 难度 | 是否提供源码 |\n| :----: | :------: | :--: | :----------: | :--: | :--: |\n| pooop | 一段有趣的描述或者背景（见下方规范），长度在50-200字之间 | WEB | 1-2小时 | 用户填写的要求中的难度 |是|\n\n**⚠️ 题目描述规范（严格遵守）**：\n- ❌ **禁止**：提及具体漏洞类型（如\"原型链污染\"、\"SQL注入\"、\"反序列化\"、\"SSRF\"、\"SSTI\"、\"XSS\"、\"文件上传\"、\"命令执行\"、\"RCE\"等）\n- ❌ **禁止**：暗示技术栈细节（如\"JWT认证\"、\"Redis缓存\"、\"Node.js特性\"等）\n- ❌ **禁止**：暗示攻击路径（如\"普通用户能否获取管理员权限\"、\"评论处理存在缺陷\"等）\n- ❌ **禁止**：使用\"漏洞\"、\"绕过\"、\"提权\"、\"污染\"、\"逃逸\"、\"沙箱\"、\"注入\"、\"执行\"等敏感词汇\n- ❌ **禁止**：在题目名称中暗示漏洞类型（如\"BlogPollution\"暗示污染漏洞）\n- ✅ **应该**：只描述业务场景和背景故事\n- ✅ **应该**：使用模糊的挑战性描述（如\"你能发现其中的秘密吗？\"）\n- ✅ **应该**：题目名称使用中性的业务名称（如\"TechBlog\"、\"BlogHub\"等）\n\n**好的示例**：\n> 某公司新上线了一套HR管理系统，用于日常人事管理。作为新入职的安全工程师，你被要求对系统进行安全评估。\n\n**坏的示例**（禁止）：\n> HR管理系统权限提升与机密泄露...系统采用JWT认证...普通员工能否通过漏洞获取FLAG？\n> 博客平台的评论和元数据处理存在深层次的设计缺陷...原型链污染...远程命令执行...\n\n## FLAG\n* 动态 flag\n\n## 知识点\n1. xxx\n\n## 解题步骤（要足够详细）\n1. ...\n```\n\n### 9.4 writeup 要求\n\n- **题目描述**：50-200字，禁止提及漏洞类型\n- **解题步骤**：详细，基于实际测试\n- **payload**：必须是实际可用的\n",
"required": true
},
{
"id": "10",
"name": "成品输出",
"order": 9,
"output": "最终文件结构",
"prompt": "删除额外的测试文件，并输出：\n```\n✅ 题目生成完成！\noutput/{timestamp}_{题目名称}/\n├── docker/\n│ ├── docker-compose.yml\n│ └── web/\n│ ├── Dockerfile\n│ ├── files/ (flag.sh, start.sh, db.sql)\n│ └── src/具体的源代码 (结构清晰，层次分明，前后端分离)\n├── exp.py\n└── writeup.md\n\n```\n\n不要输出任何上述内容以外的内容",
"required": true
}
]
},
"简单": {
"rules": {
"depth_range": [
1.5,
4
],
"diff_rate": 0.2,
"max_count": 1,
"writeup_count": 5
},
"stages": [
{
"fixed_position": true,
"id": "1",
"name": "用户输入需求",
"order": 0,
"output": "语言、漏洞、场景、难度",
"prompt": "**选择顺序**：语言 → 难度 → 漏洞 → 场景\n\n**第一步：选择语言**（如 Python、PHP、Node.js）\n\n**第二步：选择难度**\n| 难度 | 允许漏洞数量 | writeup 总数 |\n|------|-------------|-------------|\n| 入门 | 1 个 | 5 篇 |\n| 简单 | 1-2 个 | 5 篇 |\n\n**第三步：选择漏洞**（根据难度限制数量）\n\n**第四步：选择场景**（如留言板、博客、OA系统）\n\n**示例**：\n```\n语言：Python\n难度：简单（最多2个漏洞）\n漏洞：SQL注入\n场景：留言板\n```\n",
"required": true,
"system_stage": true
},
{
"condition": "knowledge_count > 1",
"id": "2",
"name": "漏洞主次分类",
"order": 1,
"output": "主漏洞/辅助漏洞分配",
"prompt": "**如果用户选择了多个漏洞**（简单难度允许2个）：\n- **主漏洞**（1 个）：核心考点，分配 3 篇 writeup\n- **辅助漏洞**（0-1 个）：辅助利用，分配 2 篇 writeup\n\n**入门难度只允许1个漏洞，跳过此阶段**\n",
"required": false
},
{
"description": "根据用户输入和配置的脚本，从知识库中筛选并获取相关的知识点和 Writeup",
"id": "3",
"knowledge_script_code": "",
"knowledge_script_instruction": "",
"knowledge_script_name": "",
"knowledge_script_path": "",
"name": "知识库获取",
"order": 2,
"output_format": "json",
"prompt": "### 3.1 获取学习材料（必须使用 choice.py）\n*⚠️ 重要：必须使用 Bash 工具运行 choice.py 获取 writeup，禁止使用 WebSearch/WebFetch**\n\n```bash\npython3 data/scripts/choice.py --difficulty=<难度> --count=<数量> \"漏洞名称\"\n```\n\n**⚠️ 漏洞名称必须使用用户输入的完整名称，禁止简化或缩写！**\n- ✅ 正确：`\"SSTI模板注入\"` `\"SQL注入\"` `\"文件上传漏洞\"`\n- ❌ 错误：`\"SSTI\"` `\"SQL\"` `\"文件上传\"`\n\n**示例**：\n```bash\npython3 data/scripts/choice.py --difficulty=简单 --count=3 \"SQL注入\"\npython3 data/scripts/choice.py --difficulty=简单 --count=2 \"信息泄露\"\npython3 data/scripts/choice.py --difficulty=简单 --count=5 \"SSTI模板注入\"\n```\n\n**choice.py 会输出选中的 writeup 文件名，然后使用 Read 工具读取 `data/writeups` 目录下对应的 .md 文件**\n",
"required": true,
"system_prompt": "根据用户输入的需求，使用配置的知识库筛选脚本，从知识库中获取相关的知识点和 Writeup 文件。",
"system_stage": true,
"user_extension": ""
},
{
"id": "4",
"name": "知识整理",
"order": 3,
"output": "可借鉴技巧清单",
"prompt": "**输出可借鉴技巧清单**（简化版）：\n\n```markdown\n## 可借鉴技巧清单\n\n| 技巧 | 来源 | 代码片段 | 适用场景 |\n|------|------|---------|---------|\n| Flask SSTI触发 | WP#1 | `render_template_string(f'...')` | Python Web |\n| SQL注入绕过 | WP#2 | `' OR 1=1--` | 登录表单 |\n```\n\n**要求**：至少提取 3 个可借鉴的代码片段\n",
"required": true
},
{
"id": "5",
"name": "题目设计",
"order": 4,
"output": "利用链、核心代码预写",
"prompt": "### 5.1 设计目标\n\n- **差异度**：入门 ≥20%，简单 ≥30%\n- **深度**：入门 1.5-4.0，简单 2.5-5.0\n- **趣味性**：入门 0-1 个啊哈时刻，简单 1 个啊哈时刻\n\n### 5.2 利用链设计\n\n```markdown\n| 步骤 | 类型 | 技术点 | 深度 | 知识来源 |\n|------|------|--------|------|---------|\n| Step 1 | 信息收集 | robots.txt | 1/10 | WP#1 |\n| Step 2 | 漏洞利用 | SQL注入 | 3/10 | WP#2 |\n```\n\n### 5.3 核心代码预写（必须！）\n\n**在设计阶段就必须写出真实的漏洞代码（非伪代码）**：\n\n```markdown\n### 漏洞触发代码（5-10行真实代码，包含导入）\n\n❌ 安全写法（不能触发）：\n```python\ncursor.execute(\"SELECT * FROM users WHERE id = ?\", (user_id,))\n```\n\n✅ 漏洞写法（能触发）：\n```python\ncursor.execute(f\"SELECT * FROM users WHERE id = {user_id}\")\n```\n\n### exp 核心代码（5-10行真实代码）\n```python\nimport requests\npayload = \"1 OR 1=1--\"\nr = requests.get(f\"{url}/user?id={payload}\")\n```\n\n### 依赖清单\n- Flask==2.0.1\n- requests==2.28.0\n```\n\n**⚠️ 如果写不出来，说明设计不可行，需要调整**\n\n### 5.3.1 代码可运行性自检\n\n在写完核心代码后，回答以下问题：\n\n1. **导入完整吗？** 代码中用到的所有模块都有 import 吗？\n2. **路由正确吗？** exp 请求的路径和后端定义的路由一致吗？\n3. **参数名一致吗？** exp 发送的参数名和后端接收的参数名一致吗？\n4. **响应格式对吗？** exp 期望的响应格式和后端返回的格式一致吗？\n\n### 5.4 简易 exp 草稿（用于 Docker 测试）\n\n**在设计阶段输出简易 exp 草稿，用于后续 Docker 测试验证**：\n\n```python\n# 简易 exp 草稿（仅用于测试，阶段 7 会完善）\nimport requests\n\nurl = \"http://localhost:端口\"\n# Step 1: xxx\nr1 = requests.get(f\"{url}/路径\")\n# Step 2: 漏洞利用\npayload = \"xxx\"\nr2 = requests.post(f\"{url}/漏洞路径\", data={\"参数\": payload})\n# 预期结果：能看到 flag\nprint(r2.text)\n```\n\n### 5.5 设计摘要\n\n```\n### 设计摘要\n- 题目名称：XXX\n- 利用链：Step1 -> Step2\n- 黑名单：xxx（如果有）\n- 关键 payload：xxx\n- 容器端口：5000\n```\n",
"required": true
},
{
"id": "6",
"name": "质量检查",
"order": 5,
"output": "验证清单",
"prompt": "### 检查清单\n\n- [ ] **深度达标**：平均深度、最高深度符合要求\n- [ ] **漏洞覆盖**：用户要求的所有漏洞都在利用链中\n- [ ] **代码可行**：阶段 5.3 的核心代码能正常运行\n- [ ] **payload 兼容**：黑名单不会阻断 payload\n\n**若检查失败 → 返回阶段 5 修改**\n",
"required": true,
"skip_forbidden": true
},
{
"id": "7",
"name": "代码生成",
"order": 6,
"output": "后端代码、Docker 文件",
"prompt": "### 7.1 生成原则\n\n1. **完整性**：包含所有设计的功能点和漏洞点\n2. **零注释**：代码中禁止任何注释\n3. **真实性**：模拟真实业务逻辑\n4. **隐蔽性**：漏洞点自然隐藏在业务逻辑中\n\n**提供源码时**：禁止硬编码管理员密码\n**不提供源码时**：可以硬编码\n\n### 7.2 增量生成顺序（每步必须验证）\n\n**⚠️ 本阶段只生成题目代码和 Docker 文件，exp.py 和 writeup.md 在阶段 7 生成**\n\n1. **后端代码**\n- 检查：所有 import 语句是否完整\n- 检查：路由定义是否正确（路径、方法）\n- 检查：漏洞触发点是否使用\"漏洞写法\"\n\n2. **依赖文件**\n- 检查：requirements.txt 包含所有导入的模块\n- 检查：版本号是否明确指定\n\n3. **前端文件**\n- 检查：表单 action 路径与后端路由一致\n- 检查：input name 与后端参数名一致\n- 检查：模板语法不与框架冲突\n\n4. **Docker 文件**\n- 检查：EXPOSE 端口与应用监听端口一致\n- 检查：docker-compose ports 映射正确\n- 检查：COPY 路径正确\n\n**⚠️ 每步生成后立即验证，发现问题立即修复**\n\n### 7.3 文件结构\n\n```\noutput/{timestamp}_{题目名称}/\n├── docker/\n│ ├── docker-compose.yml\n│ └── web/\n│ ├── Dockerfile\n│ ├── files/ (flag.sh, start.sh)\n│ └── src/\n```\n\n**注意：exp.py 和 writeup.md 在阶段 9 生成**\n\n### 7.4 核心文件要求\n\n**docker-compose.yml**：\n- 外部端口：随机 42500-42600\n- 只允许 1 个 web 容器\n- 设置唯一 container_name\n\n**Dockerfile**：\n- 使用官方镜像\n- 包含 `ENV DASFLAG DASCTF{test12345}`\n- 优先使用国内源\n\n**flag.sh**：\n```bash\n#!/bin/bash\necho $DASFLAG > /flag.txt\nexport DASFLAG=nonono\nrm -f /flag.sh\n```\n\n### 7.5 设计-实现一致性验证\n\n生成完成后，验证：\n- [ ] 每个设计步骤都有对应的代码实现\n- [ ] 漏洞触发点使用的是\"漏洞写法\"\n- [ ] 路由路径、参数名与阶段 5 设计一致\n",
"required": true
},
{
"id": "8",
"name": "Docker 构建与测试",
"order": 7,
"output": "容器验证",
"prompt": "### 8.1 分层验证（按顺序）\n\n1. **容器启动**：`docker-compose -p ctf_test up -d --build`\n2. **服务可用**：`curl http://localhost:端口/`\n3. **基础功能**：测试正常功能（注册、登录）\n4. **漏洞触发**：使用阶段 3.4 的简易 exp 草稿测试漏洞是否可触发\n\n**⚠️ 每层通过后再进入下一层，失败时立即修复代码，不要继续**\n\n### 8.2 测试清单\n\n- [ ] Docker 容器正常启动\n- [ ] 前端页面正常显示\n- [ ] 前端无测试账号泄露\n- [ ] 简易 exp 能触发漏洞并获取 FLAG\n\n**⚠️ 必须全部通过后才能进入阶段 9**\n",
"required": true
},
{
"id": "9",
"name": "exp 和 writeup",
"order": 8,
"output": "exp.py、writeup.md",
"prompt": "**⚠️ 只有阶段 8 测试全部通过后，才能进入本阶段**\n\n### 9.1 完善 exp.py\n\n基于阶段 5.4 的简易 exp 草稿，完善为标准格式：\n\n```python\n#!/usr/bin/python\n# -*- coding: utf-8 -*-\nimport re, sys, requests\n\nHOST, PORT, FLAG = sys.argv[1:4]\n\ndef exp(ip, port):\n# 基于简易 exp 草稿完善\nr = requests.get(f\"http://{ip}:{port}/...\")\nflag = re.findall('DASCTF{(.*?)}', r.text)[0]\nreturn flag\n\nif __name__ == '__main__':\nassert exp(HOST, PORT) == FLAG\nprint(\"Pass!\")\n```\n\n### 9.2 运行 exp.py 验证\n\n```bash\ncd output/{timestamp}_{题目名称}/\npython3 exp.py localhost 端口 test12345\n```\n\n**⚠️ 必须输出 `Pass!` 才能继续编写 writeup**\n\n如果测试失败：\n1. 检查 exp.py 的请求路径、参数名是否与后端一致\n2. 检查 payload 是否被过滤\n3. 修复后重新运行测试\n\n### 9.3 编写 writeup.md（严格按照如下格式）\n\n```markdown\n# 题目名 的解题思路\n\n## 题目信息\n| 题目名 | 题目描述 | 类型 | 预计解题时间 | 难度 | 是否提供源码 |\n| :----: | :------: | :--: | :----------: | :--: | :--: |\n| 题目名 | 一段有趣的描述或背景（50-200字，禁止提及漏洞类型） | WEB | 1-2小时 | 简单 | 是 |\n\n## 知识点\n1. xxx\n2. xxx\n\n## 解题步骤\n\n### Step 1: xxx\n（基于实际测试过程描述）\n\n### Step 2: xxx\n（包含实际的 payload）\n\n## Flag\nDASCTF{test12345}\n```\n\n### 9.4 writeup 要求\n\n- **题目描述**：50-200字，禁止提及漏洞类型\n- **解题步骤**：详细，基于实际测试\n- **payload**：必须是实际可用的\n\n\n\n### 附录 A：常见错误预防\n\n| 错误类型 | 预防措施 |\n|---------|---------|\n| 模板路径错误 | 确保文件在 `templates/` 目录下 |\n| 端口不一致 | Dockerfile EXPOSE 与 docker-compose ports 保持一致 |\n| 导入缺失 | 检查 requirements.txt 包含所有导入的模块 |\n| 漏洞无法触发 | 确认使用\"漏洞写法\"而非\"安全写法\" |\n| payload 被过滤 | 确认黑名单不包含 payload 中的关键字符 |\n| 路由不匹配 | 确认 exp.py 请求路径与后端路由完全一致 |\n| 参数名不匹配 | 确认前端 input name、exp 参数名、后端参数名三者一致 |\n\n### 附录 B：代码生成前最终检查（必须通过）\n\n**在生成每个文件前，大声回答以下问题：**\n\n#### 后端代码\n```\n□ 我用的是什么框架？版本是多少？\n□ 漏洞触发点在哪一行？用的是\"漏洞写法\"还是\"安全写法\"？\n□ 所有 import 都写了吗？\n□ 路由路径是什么？请求方法是 GET 还是 POST？\n□ 接收参数用的是什么名字？\n```\n\n#### exp.py\n```\n□ 请求的 URL 路径和后端路由完全一致吗？\n□ 请求方法和后端一致吗？\n□ 参数名和后端接收的参数名一致吗？\n□ payload 会被黑名单过滤吗？\n□ 如何从响应中提取 flag？正则表达式对吗？\n```\n\n#### Docker\n```\n□ 应用监听的端口是多少？\n□ Dockerfile 的 EXPOSE 端口一致吗？\n□ docker-compose 的 ports 映射正确吗？\n□ COPY 的源路径和目标路径都对吗？\n□ start.sh 中启动命令正确吗？\n```\n\n**⚠️ 如果任何一个问题回答不上来，说明设计不够清晰，需要返回阶段 3 补充**\n",
"required": true
},
{
"id": "10",
"name": "成品输出",
"order": 9,
"output": "最终文件结构",
"prompt": "删除额外的测试文件，并输出：\n```\n✅ 题目生成完成！\noutput/{timestamp}_{题目名称}/\n├── docker/\n│ ├── docker-compose.yml\n│ └── web/\n│ ├── Dockerfile\n│ ├── files/\n│ └── src/\n├── exp.py\n└── writeup.md\n```\n",
"required": true
}
]
}
}
}