Skip to main content Skills Marketplace Découvrez et explorez les compétences IA créées par la communauté.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Copier le promptAfficher les détails du prompt Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/haibo3434358/ScareAISec --skill discovery-universal-methodologyLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Télécharger Zip Téléchargement... Métiers associés SOC
Basé sur la classification professionnelle SOC
name discovery-universal-methodology description 通用漏洞发现方法论 — 当遇到不在已有SKILL覆盖范围内的场景时,教LLM如何系统性地发现漏洞。覆盖:输入点穷举、响应差异分析、边界条件探测、未知技术栈适应、容易被忽略的攻击面。 enabled true category discovery priority 10 vuln_types ["通用","未知场景"] triggers ["不确定怎么测试","未知技术栈","没有对应的SKILL","通用测试方法"] synonyms ["universal-discovery","general-methodology"] metadata {"tags":"discovery,universal,methodology,通用,方法论,输入点,响应差异,边界条件,攻击面","category":"discovery","type":"methodology"}
通用漏洞发现方法论
适用场景 :当遇到不在已有 SKILL 覆盖范围内的功能/技术栈时
核心思想 :所有漏洞的本质 = 输入未被正确处理 + 信任边界被突破
关于本 Skill 的使用边界
本 Skill 本身的定位就是兜底 ——专门用于其他专项 Skill 没覆盖的场景。正因为是兜底,它特别容易反过来锁死你的判断 :你跑完 Step 1–5 + 最低必测自检,会下意识觉得"通用方法论都走完了,应该没问题"。但事实是:
本 Skill 的"输入点穷举"、"差异分析矩阵"、"边界条件"、"技术栈识别表"都是常见模式快照 ,不可能覆盖所有目标。
当你看到一个完全没列在本 Skill 任何表格里 的入口(例如 WebRTC SDP、postMessage、Service Worker、IndexedDB、HTTP/2 伪头、TLS SNI、文件元数据 EXIF/ID3、ZIP 注释、PNG tEXt chunk、字体子表、protobuf Any 字段、gRPC metadata、IPC、共享内存、缓存键、CDN 转发头),直接按你的推理执行 ,不要因为表里没列就忽略。
当你的分析指向某个业务专有逻辑漏洞、某个开源组件的 nday、某个完全未公开的 0day 思路时,信任你的分析 ,本 Skill 没写不代表不存在。
如果在某一步已经获得清晰证据(例如改一个字段返回了别人的数据),不必再机械执行后续 Step。
如果某个表格项确实不适用,标记原因即可,不要为凑数而硬测。
🧠 第一性原理
漏洞 = 数据与指令不分离
= 用户输入到达了不该到达的地方
= 信任假设被违背
发现漏洞 = 找到所有输入点 × 测试所有可能的异常输入 × 观察异常响应
📋 Step 1:穷举所有输入点
💡 决策树警告 :下面的"显式 / 隐式 / 业务逻辑"三张表是最常见输入点的快照 ,不是穷尽列举 ,更不能反推"这三张表都测过 = 输入点测完了" 。
特别注意以下"输入点压根不在表里、但完全可控"的真实场景:
浏览器侧隐藏通道 :postMessage、window.name、document.referrer、localStorage / sessionStorage / IndexedDB 跨页污染、Service Worker 拦截后注入、SharedWorker 共享状态、Broadcast Channel API、DOM clobbering 触发的 window 属性覆盖(<a id=cookie> 让 window.cookie 变成元素)。
HTTP/2、HTTP/3 与协议层 :HTTP/2 伪头(:method、:path、:authority、:scheme)、HPACK/QPACK 头部压缩字典、HTTP/2 CONTINUATION 帧、ALPN 协商、TLS SNI 扩展(SNI 注入)、TLS ALPS、WebSocket 握手 Sec-WebSocket-Protocol / Sec-WebSocket-Extensions、HTTP Upgrade 头切换协议。
DNS / 网络层输入 :DNS 查询名本身(DNS 重绑定、长域名拆 label、IDN 同形字)、原始 socket 字节、TCP options、ICMP payload、SMTP 命令注入、IMAP/POP3 命令注入、LDAP filter 注入、SIP message。
文件元数据 / 容器格式 :EXIF 字段(GPS、Make、Software 注入到下游)、ID3 标签(音频)、PDF metadata(Title/Author/Producer)、Office docProps、ZIP 注释/文件名/Extra Field、PNG tEXt/iTXt chunk、SVG <script>、字体 OpenType name 表、SQLite 数据库文件、protobuf 字段、Avro/Parquet schema、gRPC metadata、CBOR tagged item、msgpack ext type。
Any
缓存与代理层 :缓存键(Cache Key Injection / unkeyed header poisoning)、CDN 转发头(X-Forwarded-Host、Forwarded、True-Client-IP、Fastly-Client-IP、CF-Connecting-IP)、反向代理重写后的内部头(X-Original-URL、X-Rewrite-URL、X-Override-URL)、HTTP 请求走私的 CL.TE/TE.CL/TE.TE。
客户端 / 移动端通道 :Android Intent extras、URL Scheme(appname://...)、iOS Universal Link、Electron IPC、WebView jsBridge、WKScriptMessageHandler、剪贴板、推送通知 payload、深链接参数。
业务异步通道 :MQ 消息体(Kafka/RabbitMQ/RocketMQ)、Webhook 回调、定时任务参数、cron 表达式可控、第三方回调(OAuth callback、支付回调、CDN 推流回调)、邮件入站解析(imap-fetch 后处理)。
以现场为准 :只要某个数据有从外部进入系统的可能 ,无论它在不在表里、长得像不像 HTTP 参数,都该作为输入点来测。不要用本 Skill 的 3 张表反向限制"什么算输入点" 。
显式输入(容易发现) 输入位置 示例 常见漏洞 URL 路径参数 /api/user/123IDOR, SQLi, LFI GET 查询参数 ?id=1&sort=nameSQLi, XSS, SSRF POST body {"name":"test"}所有注入类 文件上传 multipart file RCE, XSS, XXE Cookie session=abc123SQLi, 反序列化
隐式输入(容易忽略!) 输入位置 示例 常见漏洞 HTTP Header User-Agent, Referer, X-Forwarded-For SQLi, XSS, SSRF, Log4j Content-Type application/json → xml XXE Accept-Language zh-CN → {{7*7}} SSTI 文件名 filename="shell.php" RCE JSON 键名 {"<script>":"value"}XSS 数组索引 items[0][id]=1类型混淆 HTTP 方法 GET → PUT/DELETE/PATCH 未授权操作 协议版本 HTTP/1.1 → HTTP/2 Smuggling 编码声明 charset=utf-7 XSS 路径分隔符 /api/..;/admin权限绕过
业务逻辑输入(最容易忽略!) 输入 测试方式 漏洞 数量/金额 负数、0、小数、极大值 逻辑漏洞 时间/日期 过去时间、未来时间、时区差异 竞态、逻辑 状态转换 跳过步骤、重复步骤、逆序 流程绕过 并发 同时发送相同请求 竞态条件 引用关系 A 引用 B,修改 B 的 ID IDOR 批量操作 单个接口批量提交 越权、DoS 默认值 不传某个参数 默认权限过高 类型混淆 字符串→数组、数字→对象 类型绕过
📋 Step 2:响应差异分析
核心方法:对比正常请求和异常请求的响应差异 正常请求 → 响应 A
异常请求 → 响应 B
如果 A ≠ B → 后端对输入做了处理 → 可能存在漏洞
差异类型:
- 状态码不同(200 vs 500)→ 语法错误 → 注入
- 响应长度不同 → 条件判断 → 布尔盲注
- 响应时间不同 → 延时执行 → 时间盲注
- 响应内容不同 → 数据泄露 → 信息泄露
- 响应头不同 → 服务端行为变化 → 配置问题
差异分析矩阵 输入变化 观察指标 如果有差异说明 加单引号 ' 状态码/错误信息 SQL 注入 加 {{7*7}} 响应中出现 49 SSTI 加 <script> 响应中原样出现 XSS 改 ID 为其他用户 返回不同数据 IDOR 加 ; sleep 5 响应延迟 5 秒 命令注入 改 URL 为内网 响应内容变化 SSRF 删除 Token/Cookie 仍然返回数据 未授权访问 改 HTTP 方法 返回不同结果 方法绕过 加超长输入 500 错误 缓冲区/DoS 加特殊字符 \n\r\t\0 行为异常 注入类
📋 Step 3:边界条件探测
数值边界 0, -1, -999999
2147483647 (INT_MAX)
2147483648 (INT_MAX + 1 → 溢出)
9999999999999999 (超大数)
0.1, 0.0001, 1e308
NaN, Infinity, -Infinity
null, undefined, ""
字符串边界 空字符串 ""
超长字符串(10000+ 字符)
特殊字符:' " \ / < > & | ; ` $ { } [ ] ( ) # @ ! % ^ * ~ ?
NULL 字节:%00
Unicode:\u0000, \uffff, 表情符号 🎉
换行符:\r\n, \n, \r
制表符:\t
不可见字符:\x01-\x1f
类型边界
"id" : "1" → "id" : [ "1" ] → "id" : [ 1 , 2 , 3 ]
"id" : "1" → "id" : { "$gt" : "" } → "id" : { "__proto__" : { } }
"id" : 1 → "id" : "1 OR 1=1"
"admin" : false → "admin" : true → "admin" : 1 → "admin" : "true"
📋 Step 4:未知技术栈适应
技术栈识别信号 信号 技术栈 重点测试 响应头 X-Powered-By: Express Node.js PP, NoSQL, SSTI(Pug/EJS) 响应头 Server: Apache + .php PHP LFI, 反序列化, XXE Cookie JSESSIONID Java 反序列化, SSTI(FreeMarker), JNDI Cookie ASP.NET_SessionId .NET 反序列化(ViewState), XXE 响应头 X-Django-Version Python/Django SSTI, ORM注入 路径 /api/v1/ + JSON REST API IDOR, 批量操作, 权限 路径 /graphql GraphQL Introspection, 批量查询 WebSocket 升级 实时应用 CSWSH, 消息注入 .aspx 后缀ASP.NET ViewState反序列化 __RequestVerificationTokenASP.NET MVC CSRF Token 绕过 csrfmiddlewaretokenDjango CSRF 配置 _token in formLaravel CSRF, 反序列化
遇到完全未知的技术时 1. 发送各种异常输入,观察错误信息
- 错误信息中的关键词可以识别技术栈
- 如 "Traceback" → Python, "Exception" → Java, "Fatal error" → PHP
2. 测试通用漏洞(不依赖技术栈)
- IDOR(改 ID)
- 未授权访问(删 Token)
- 逻辑漏洞(改金额/数量)
- 信息泄露(错误信息/调试接口)
3. 逐步缩小范围
- 先确认输入是否被处理
- 再确认处理方式(拼接? 解析? 执行?)
- 最后选择对应的注入方式
📋 Step 5:容易被忽略的攻击面
1. 二级功能(非核心业务) - 导出功能(PDF/Excel/CSV)→ SSRF, 注入, XXE
- 导入功能(上传 CSV/XML/JSON)→ XXE, 注入, RCE
- 预览功能(URL 预览/文件预览)→ SSRF, LFI
- 分享功能(生成分享链接)→ IDOR, 信息泄露
- 通知功能(邮件/短信/Webhook)→ SSRF, 注入
- 日志/审计功能 → 信息泄露, 二次注入
- 搜索建议/自动补全 → 注入, 信息泄露
2. 非标准接口 - /actuator(Spring Boot)→ 信息泄露, RCE
- /debug, /trace, /metrics → 信息泄露
- /swagger, /api-docs → API 结构泄露
- /.env, /config → 配置泄露
- /admin, /manage → 未授权访问
- /backup, /.git → 源码泄露
- /upload, /file → 文件操作
- /proxy, /fetch, /url → SSRF
3. 时序相关 - 注册 → 验证邮箱 → 激活:跳过验证步骤
- 下单 → 支付 → 发货:修改支付后的订单
- 申请 → 审批 → 执行:绕过审批直接执行
- 登录 → 2FA → 访问:绕过 2FA
4. 多步骤操作中的漏洞 - Step 1 验证了权限,Step 3 没验证 → 直接访问 Step 3
- Step 1 设置了金额,Step 2 可以修改 → 篡改金额
- 整个流程有 CSRF 保护,但某一步没有 → 针对该步 CSRF
🎯 发现信号总结
必须立即深入测试的信号 信号 含义 行动 500 错误 输入导致后端异常 立即测试注入 响应时间突变 可能触发了延时操作 时间盲注 错误信息含技术细节 信息泄露 + 注入线索 利用信息构造 payload 不同用户看到不同数据 权限控制存在 测试 IDOR 参数名含 url/path/file/cmd 可能直接使用输入 SSRF/LFI/CMDI 响应中原样反射输入 无过滤 XSS/注入 JSON 响应含大量字段 可能有隐藏字段 信息泄露 接口无需认证 权限缺失 未授权访问
⛔ 最低必测自检
✅ 测试了所有可见参数的注入(', ", {{}}, ${}, ;, |)
✅ 测试了 HTTP Header 注入(至少 User-Agent, Referer, X-Forwarded-For)
✅ 测试了 IDOR(修改 ID/UUID 参数)
✅ 测试了未授权访问(删除 Token/Cookie)
✅ 测试了类型混淆(字符串→数组→对象)
✅ 测试了边界值(0, -1, 超大数, 空字符串, 超长字符串)
✅ 测试了 HTTP 方法切换(GET→POST→PUT→DELETE)
✅ 检查了响应中是否有敏感信息泄露
⚠️ Skill 边界与逃逸 本 Skill 是辅助参考 ,不是束缚你的脚手架。作为兜底通用方法论,它特别容易反过来成为新的枷锁 ——请在以下情况下主动跳出本 Skill 的清单 ,按你自己的判断行动:
现场证据与本 Skill 矛盾时
例如本 Skill 说"500 错误 = 输入导致后端异常 = 立即测试注入",但你看到目标无论传什么都返回固定 200 + 空体(被全局兜底 try-catch 包了),这种"看似没差异"恰恰可能掩盖了真正的命中 ——切到 OOB 探针(DNSLog、Burp Collaborator)、切到时间侧信道、切到错误日志/审计日志查看;以现场为准,不要被"差异分析矩阵"列出的 10 行限制思路。
反过来,本 Skill 说"响应不同 → 可能存在漏洞",但你看到的不同其实只是负载均衡返回不同节点的 banner、或缓存命中状态变化、或 trace id 时间戳差异——这种"差异"是噪声,不是漏洞信号。
遇到本 Skill 没列出的入口或链路
例如:postMessage 跨窗口通信、Service Worker 拦截改包、IndexedDB 跨源污染、WebRTC SDP 注入、HTTP/2 伪头、TLS SNI 注入、文件元数据(EXIF/ID3/ZIP 注释/PNG tEXt/字体子表)、protobuf Any 字段、gRPC metadata、缓存键投毒、CDN 转发头、MQ 消息体、Webhook 回调、Android Intent extras、Electron IPC、WebView jsBridge、剪贴板、深链接、第三方回调(OAuth/支付/CDN)。
这些路径不在 Step 1–5 里,但完全可能是真实漏洞点。看到就追,别等清单授权 。
需要跨 Skill / 跨维度联动时
通用方法论真正的价值是作为入口扫描器 ,发现可疑信号后应立刻切换到对应专项 Skill (SQLi、XSS、SSRF、IDOR、SSTI、反序列化、文件上传、命令注入、JWT、OAuth 等)做深挖。
不要因为当前在"通用方法论 Skill"里就只用本 Skill 的清单去测——一旦看到"参数名含 url/path/file/cmd"或"@type 字段"或"{{7*7}} 被解析",立即跳到专项 Skill ,不要在通用清单里硬测。
反过来,专项 Skill 都跑完后,也可以回到本 Skill 检查"有没有漏掉的输入维度"。
"Step 1–5 + 自检 8 条都跑完 = 接口安全" 是最危险的错觉
这是兜底 Skill 最容易制造的幻觉。通用清单只是最低门槛 ,不是充分条件 。
真正的判断标准是:你是否已经基于实际观察 + 业务理解,形成了"此处不可利用 / 已可利用 / 还有未验证的疑点"的有依据结论 。
没形成结论之前,继续推理;形成结论之后,不必再硬走流程。
特别注意:业务逻辑漏洞 几乎都不会被本 Skill 的清单直接发现——它们需要你理解业务流程、识别信任假设、构造异常路径。这部分完全靠你的推理 ,本 Skill 帮不上。
你的推理优先级永远高于本 Skill
本 Skill 的所有表格、清单、信号都是公开知识的快照 ,不可能覆盖所有目标 ,也会过时。
当你的分析指向某个本 Skill 没写的方向时(例如某个业务专有的认证假设、某个开源中间件的近期 nday、某个完全未公开的 0day 思路、某个被业务方魔改过的常见框架),信任你的分析 ,不要因为"清单里没有"就放弃。
反过来,当本 Skill 的某条建议在当前场景明显不适用时,跳过它即可,不要为了凑数硬测 ——例如目标根本不接受 JSON,就不必硬测"类型混淆字符串→数组"。
一句话:本 Skill 是地图,不是轨道 。作为兜底通用方法论,它更容易让你误以为"地图就是全境"——记住,它只是所有专项 Skill 的并集中最常见的子集 ,目标的真实攻击面永远比任何清单大。具体怎么走、要不要走小路,由你根据现场决定。