我把自己做安全审查的一套方法，做成了一个 AI Skill

创作声明

AI 协作说明：这篇文章不是我一个字一个字写出来的，准确地说，它是我和 GPT 一起完成的。这套 Web 安全体检流程的核心思路、实际经验、检查原则和判据设计来自我自己的实践；之后我把这些内容交给 GPT，让它帮我梳理、结构化、封装成 Agent Skill，并协助完成本文的整理和写作。所以你现在看到的这篇文章，确实是 GPT 帮我写的；这个 Skill，也确实有 GPT 的大量参与。但这里面最重要的东西------为什么这么设计、哪些地方必须停、什么才算证据，以及整个流程本身------是我自己的经验。
我觉得这恰好也是这次实践最值得分享的地方。

前言

最近做了一件挺有意思的事情。

我把自己在 Web 站点安全审查过程中积累的一套方法，整理成了一套可以让 AI Agent 执行的 Skill。

它叫：

web-security-blackbox

简单来说，就是给它一个经过授权的 Web 站点，让 Agent 按照一套固定的流程，完成一次有边界、有判据、有证据、有交付物的黑盒安全体检。

这不是我第一次让 AI 帮我做安全检查。

真正让我感兴趣的是另外一件事情：

一个人的工作经验，到底能不能被拆解成 AI 可以执行的工作流？

这次算是做了一次比较完整的尝试。

一、为什么我会想到把它做成 Skill？

以前我们做安全检查，很多东西其实都在人的脑子里。

比如看到一个：

text 复制代码

/user/detail?user_id=123

有经验的人第一反应可能不是：

"这里存在 IDOR。"

而是：

"这个 user_id 到底应该由谁决定？"

然后才会继续判断：

当前用户是谁？
这个 ID 是不是客户端可控？
后端有没有做归属校验？
有没有必要做第二身份差分？
能不能用一个不存在的 ID 先验证？
有没有必要碰真实用户数据？

这其实是一连串的判断。

再比如 SQL 注入。

一个参数加 ' 之后返回：

text 复制代码

参数错误

新人可能会觉得：

SQL 注入！

但实际上，这个现象可能只是：

前端过滤；
WAF；
后端参数校验；
统一异常处理；
ORM 参数化；
甚至只是一个普通的业务错误。

所以真正重要的不是：

"我会不会打 payload。"

而是：

"我能不能正确解释这个现象。"

这些东西，才是我真正想让 AI 学会的。

二、所以我没有先写"扫描器"，而是先整理方法论

我把整个过程拆成了一条状态机：

text 复制代码

INIT
 ↓
AUTH_GATE
 ↓
SCOPE_GATE
 ↓
PASSIVE_DISCOVERY
 ↓
ATTACK_SURFACE
 ↓
CHECK_SELECTION
 ↓
SAFE_PROBES
 ↓
EVIDENCE_CLASSIFICATION
 ↓
REPORT
 ↓
CLOSE

看起来很普通。

但这里面其实有一个非常重要的变化：

安全检查不再是"扫描"，而是一套受约束的决策流程。

三、第一步不是扫描，而是确认：我有没有资格测？

这是我在整个流程里最看重的一点。

很多安全工具的逻辑是：

text 复制代码

输入 URL
 ↓
开始扫描

但我设计的逻辑是：

text 复制代码

输入 URL
 ↓
你是谁？
 ↓
你和这个系统是什么关系？
 ↓
你获得了什么授权？
 ↓
允许测试什么？
 ↓
允许测试到什么程度？
 ↓
确认
 ↓
开始

因为：

能访问，不代表被授权测试。

公网网站能打开，不代表我们就有权对它进行安全测试。

所以 Skill 里面有一个强制的"开工确认卡"。

用户需要明确回答：

目标是谁；
自己和目标的关系；
检测范围；
检测时间；
请求量级；
哪些事情明确不做；
是否允许测试写入；
中途撤回授权如何处理。

在这些信息没有确认之前：

不发测试请求。

甚至连"先帮你看看"都不行。

四、第二个原则：先观察，再行动

我非常喜欢一个思路：

能从已有信息里得到的，就不要为了得到它再发一次请求。

所以整个流程首先做的是被动发现。

正常打开页面，通过浏览器已经产生的网络请求观察：

Server；
X-Powered-By；
Cookie；
页面框架；
XHR / Fetch；
API 路由；
登录跳转；
OIDC / SSO；
.aspx、.php、/api/ 等特征。

甚至很多时候，一次登录跳转就可以看出整个认证拓扑的一部分。

然后再根据这些信息：

决定真正值得测试什么。

这和传统的"拿着字典把所有东西扫一遍"，思路是不一样的。

五、我特别强调：不要为了证明漏洞而制造更大的风险

这是我自己做安全测试时比较在意的一件事情。

例如 IDOR。

传统验证方式很容易变成：

把自己的 ID 换成别人 ID，看能不能拿到别人的数据。

但如果这是生产系统，这个动作本身就可能已经造成了真实用户数据访问。

所以我把验证顺序设计成：

text 复制代码

合成不存在的 ID
        ↓
测试账号自己的第二身份
        ↓
必要时再考虑其他授权范围内的验证

很多情况下：

不存在的 ID 就已经可以证明后端没有正确做存在性或归属校验。

那就没有必要为了"把漏洞证据做得更漂亮"，再去读取真实用户数据。

六、另外一个我觉得很重要的原则：WAF 拦了，就停

如果测试一个参数：

第一次探针直接被 WAF 拦截。

我的处理方式不是：

换一个编码。

也不是：

换大小写。

更不是：

再想几个绕过姿势。

而是：

text 复制代码

BLOCKED_UNVERIFIED

然后停止这个测试点。

为什么？

因为：

安全检测和安全防护绕过，是两个不同的问题。

我的目标是判断：

在当前测试条件下，这个问题能不能被验证。

而不是：

想尽一切办法突破目标的安全防护。

所以 Skill 里把这一点直接写成了硬约束。

七、AI 最容易犯的错误，其实是"太喜欢给答案"

这是我这次做 Skill 的过程中一个比较深的感受。

AI 很擅长总结。

但是安全工作里：

总结得太快反而危险。

例如：

text 复制代码

输入 '
↓
返回"参数错误"

AI 很容易给出：

存在 SQL 注入风险。

但我希望它回答的是：

当前存在部分证据，但无法区分入口过滤和后端统一参数校验，需要进一步复核。

所以我把证据状态明确拆成：

text 复制代码

CONFIRMED
PARTIAL_EVIDENCE
NOT_OBSERVED
BLOCKED_UNVERIFIED
NOT_TESTED
NOT_APPLICABLE

其中有三个我特别希望大家记住：

NOT_OBSERVED ≠ SAFE

没看到，不代表没有。

BLOCKED_UNVERIFIED ≠ SAFE

被 WAF 拦截，不代表安全。

PARTIAL_EVIDENCE ≠ CONFIRMED

有异常现象，不代表漏洞成立。

这几个区别，其实比多增加几个扫描 payload 更重要。

八、我把整个检查过程做成了一张检查矩阵

目前第一版包含 17 个检查面：

C1 传输安全
C2 安全响应头
C3 Cookie
C4 令牌与凭据存放
C5 认证与会话
C6 SQL 注入
C7 XSS
C8 开放重定向
C9 IDOR / 资源归属
C10 CSRF
C11 信息泄露
C12 目录 / 文件
C13 测试写链
C14 业务滥用
C15 CORS
C16 缓存投毒
C17 子域接管

但并不是每个站点都全部跑。

而是：

先根据站点技术特征和攻击面进行裁剪。

比如：

.NET WebForms 会重点关注 ViewState / EventValidation。

.NET Core 会关注认证、中间件、API 等。

Java 会关注 Actuator、Session 等。

GraphQL 则会关注 introspection、字段级权限等。

这也是为什么我最终没有把它做成一个简单的"漏洞 checklist"。

九、我还给它加了一套"请求纪律"

因为 AI 有一个很明显的特点：

只要你告诉它"继续找"，它真的可能一直找。

所以我反而给它增加了很多限制：

单会话；
固定出口；
人速请求；
请求间隔；
每个参数最多一个确认型探针；
WAF 拦截立即停止；
不爆破；
不批量枚举；
不拖库；
不做大规模数据提取；
不执行 DDL；
不进行破坏性操作。

换句话说：

不是让 AI 尽可能多地发请求，而是让 AI 在足够少的请求里获得尽可能有价值的证据。

这其实也是我为什么比较看重"方法论"的原因。

十、最后，我希望它交付的是"体检报告"，而不是"漏洞列表"

一次完整检查结束之后，我希望看到的是：

text 复制代码

授权留痕
    ↓
检查台账
    ↓
发现的问题
    ↓
证据
    ↓
风险判断
    ↓
修复建议
    ↓
正面观察
    ↓
未覆盖项

甚至我强制要求：

报告至少包含 3 条正面观察。

因为安全检查的目的不是：

"一定要找几个漏洞出来。"

而是：

真实地告诉开发团队，这个系统目前哪里做得好，哪里存在风险，哪里还没有验证。

十一、所以我最终把它封装成了一个 Agent Skill

Skill 本身并不复杂：

text 复制代码

web-security-blackbox/
├── SKILL.md
├── references/
│   ├── authorization.md
│   ├── execution-discipline.md
│   ├── check-matrix.md
│   ├── evidence-model.md
│   └── reporting-rules.md
└── templates/
    ├── intake.md
    ├── ledger.json
    └── report.md

我没有把所有内容全部塞进 SKILL.md。

而是把：

流程

授权规则

执行纪律

检查矩阵

证据规则

报告规范

分别拆开。

这样 Agent 在执行不同阶段时，可以按需读取。

我自己比较喜欢这种方式。

因为：

Skill 应该是一套工作流，而不是一本塞满所有知识的电子书。

十二、这其实也是我最近对 AI Agent 的一个新认识

以前我们使用 AI，更多是：

"帮我写代码。"
"帮我查资料。"
"帮我生成文档。"

但如果进一步往前走一步，会发现：

真正有价值的可能是把自己的工作方法交给 AI。

比如：

一个开发者可能有自己的一套 Code Review 方法。

一个架构师可能有自己判断系统设计的标准。

一个安全工程师可能有自己排查问题的顺序。

一个项目经理可能有自己判断需求风险的方法。

这些东西过去大部分都存在人的脑子里。

现在可以尝试把它们拆成：

text 复制代码

经验
 ↓
规则
 ↓
判断条件
 ↓
工作流
 ↓
Skill
 ↓
Agent 执行

这可能才是我理解的：

AI Agent 真正开始进入工程工作的一个阶段。

AI 提效，并不意味着人退出

这里其实还有一个挺有意思的地方。

这个 Skill 里面反而有不少需要人工参与的环节：授权确认、测试范围、账号、CAPTCHA/WAF、写入操作，以及一些关键结论的判断。

乍看之下，这好像和"AI 自动化"背道而驰。

但我恰恰认为这是必要的。

AI 提效的前提，不是把人从流程里拿掉，而是先把边界划清楚。

以前做一次比较完整的站点安全审查，本身就是一件专业、繁琐、需要投入大量人力和时间的事情。现在有了这样的 Skill，虽然它并没有做到"全自动"，但至少可以让原本没有专业安全审查能力的团队，也能够借助 AI 按照一套相对规范的方法完成基础审查。

所以我理解的 AI 提效，并不是"用了 AI，以后什么都不用管了"。

恰恰相反，AI 应该让人参与更重要的判断，而不是让人变得更懒、更不会思考。

人负责目标、边界和判断，AI 负责大量执行。

这可能才是我觉得 AI 真正有价值的地方。

十三、这次我把 Skill 开放出来

所以如果你刚好也在做：

Web 开发；
安全测试；
AI Agent；
Codex / Claude Code / 其他支持 Skill 的 Agent；
内部系统安全体检；

可以拿这个 Skill 玩一下。

当然，还是要特别强调：

只用于你有权测试的系统、测试环境和合法靶场。

不要拿它去扫描网上随便找的网站。

这个 Skill 本身也把授权确认、范围限制、WAF 不绕过、真实用户数据保护等规则作为硬约束。

给出Skill地址：

👉

【ima Skill】web-security-blackbox https://ima.qq.com/skill?shareId=2627f459398843b88cac187f41eda090\&from=share

技能码：

最后再说一句

我觉得这次真正值得分享的，其实不只是这个 Skill。

而是整个过程：

我先有了一套自己长期实践出来的方法。

然后借助 GPT：

把经验重新梳理；
把隐性的判断显式化；
把流程结构化；
把规则模块化；
最后封装成一个 AI Agent 可以执行的 Skill。

所以如果非要给这件事情下一个定义，我更愿意把它称为：

"把个人经验进行 AI 化封装。"

GPT 在这里并不是替我创造经验。

它更像一个：

方法论整理器 + 工程封装器 + 协作伙伴。

而这也是我最近越来越喜欢的一种 AI 使用方式。

Skill 获取

我把目前整理好的 web-security-blackbox v1.0 放出来，里面包含：

SKILL.md
授权规则
执行纪律
C1～C17 检查矩阵
证据分类规则
报告规范
台账模板
报告模板
中文唤起说明

欢迎拿自己的测试环境试试。

如果你发现：

误判、漏检、执行不合理、某个规则设计得不够好，或者 Agent 在实际执行中出现了奇怪行为，

也欢迎反馈。

因为我更希望它不是一个"写完就结束"的 Skill。

而是一个：

通过真实使用不断迭代的方法论。

最后再次声明：本文的核心安全审查流程和实践经验来自作者本人；Skill 的结构化封装、优化及本文文字整理使用了 GPT 辅助完成。

安全测试请务必确保目标、范围和行为均获得合法授权。