文章总结： 本文记录了使用CodexAI工具对网盘系统进行安全审计的完整实战过程。通过导入三个代码仓库和现有安全报告，Codex在一天内完成了代码阅读、漏洞验证、新漏洞挖掘和报告生成，共发现19个漏洞（3严重4高危8中危4低危）。关键发现包括JWT签名绕过、硬编码密钥、无认证提权等严重漏洞，并通过三层验证排除了XSS风险。文章提供了AI辅助审计的具体操作步骤，展示了将传统一周工作量压缩至一天的高效方法。 综合评分： 90 文章分类： 代码审计,漏洞分析,安全工具,安全运营,实战经验

---

Codex安全审计实战

原创

句芒安全实验室 句芒安全实验室

句芒安全实验室

2026年6月18日 16:15 上海

在小说阅读器读本章

去阅读

我用 Codex 做了一次完整的安全审计：从 0 到 19 个漏洞，全程没有写一行代码

一个安全工程师的真实体验：把代码扔给 AI，它会读、会审、会复现、会写报告——你需要做的只是提问和验证。

---

背景

最近接手了一个网盘系统的安全审计项目——三个代码仓库（Go 后端 + Vue3 前端 + 存储服务），一份已有的安全测试报告（12 个漏洞），目标是在这基础上做一轮更深入的审查。

放在以前，这个工作量大概是这样分配的：

• 阅读代码、理解架构：1-2 天
• 逐项验证已有漏洞：1 天
• 深入审计找新漏洞：2-3 天
• 写报告、整理复现步骤：半天

加在一起，一个完整的审计周期大概要一周。

但这次我是用 Codex 来做的——整个过程我没写一行代码，所有的漏洞验证、新漏洞发现、报告撰写都是通过与 Codex 对话完成的。从开始到交付最终报告，只用了不到一天。

这篇文章就是这次实战的完整复盘。我会按时间线还原整个过程，重点讲怎么用、怎么问、效果如何。

---

开局：扔给它三个仓库和一份报告

我把项目文件夹拖进了 Codex 的工作区，然后发了第一条消息：

“根据目录下的安全报告，帮我确认是漏洞是否真实，另外这个项目下还有其他中高危的漏洞吗，如果有给出复现的方法再创建一份新的审查报告”

Codex 第一步做的事情让我有点意外——它没有急着回答，而是先去读代码了。

它同时读了：

• 原始安全报告（12 个漏洞的 Markdown）
• 三个项目的源码目录结构
• 路由文件、认证中间件、JWT 处理逻辑

然后它给出了第一个判断：

“VULN-001（alg:none 绕过）确认存在，parseTokenNoVerify 完全不验签。我来做远程复现。”

它不只是”觉得”有漏洞，而是直接在 Node.js 环境里构造恶意请求，向生产服务器发送，用返回结果来验证。

这就是第一个让我觉得不一样的地方——它不是静态分析工具那种”建议检查”的输出，而是带着攻击者的思维去做黑盒验证。

---

核心发现 1：认证体系完全透明

Codex 首先验证的是三个认证相关的严重漏洞，而且它自己把它们串成了一条完整的攻击链。

VULN-001：不需要密码，不需要密钥，什么都不需要

Codex 读了 pkg/auth.go 和 middleware.go 之后告诉我：

“认证链路中 resolveUser() 对非 dev token 的处理路径为 parseTokenNoVerify() ——这个函数调用 parser.parseWithoutVerify()，是 golang-jwt 库中完全不执行任何签名验证的方法。”

然后它在 Node.js 里构造了一个 alg:none 的 JWT（没有签名部分，只有 header 和 payload），用 curl 往生产服务器打了一个 /api/v1/user/profile 请求。

服务器返回了：

ounter(lineounter(line{"code":0,"data":{"username":"auditor-test",  "uid":"usr_e38c9ab4...","org_id":"org-default"}}

一个完全不存在于系统中的账号名，被服务器接受了。服务器还自动为它创建了数据库记录，分配了真实的 user_id。

VULN-002：一个四字节的”密钥”

接下来 Codex 扫描了 JWT 密钥的配置。它发现：

“文件上传/下载 token 使用硬编码的弱密钥（仅 4 字节，远低于 HS256 推荐的 32 字节）。密钥在源码中三处硬编码。”

更关键的是，存储服务的下载端点 validateFileAccess只校验 file_id，不校验 owner_id。

Codex 当场用该硬编码密钥伪造了一个下载 token，直接往存储服务（绕过了业务后端）发请求——文件被成功下载。

VULN-003：提权只需要一个 POST

这是 Codex 自己发现的——原报告中只提到 dev 模式会暴露普通 token，但 Codex 在审计 auth.go 时发现了 switchRole 函数：

“switchRole 仅检查 config.isDev()，完全不验证调用者身份。任何人无需任何认证 token 即可直接提权到 super_admin。”

它验证的方式简单粗暴：不带任何 Authorization 头，直接 POST 一个 JSON 过去——服务器返回了超管 token。

这时 Codex 把三个漏洞串成了一条完整的攻击链：

ounter(lineounter(lineounter(line未认证攻击者 → alg:none伪造身份 → 枚举平台用户    → 冒充目标列举文件 → 硬编码密钥伪造下载token → 越权下载    或者：switchRole → 直接获得超管权限

到这里，我已经确认了 3 个严重 + 4 个高危 + 几个中危漏洞。但接下来才是重头戏。

---

深入挖掘：我问了一个关键问题

验证完已有漏洞后，我提了一个问题：

“现在系统的增删改查等功能是否存在 XSS 漏洞呢？另外这个系统即然可以上传任意文件，有没有可能上传的文件解析后导致存储 XSS 呢？”

Codex 的处理方式让我印象深刻——它不是随便说”可能有”或”应该没有”，而是做了三层验证：

第一层：前端代码全量扫描

ounter(linerg -r 'v-html|innerHTML|dangerouslySetInnerHTML' frontend/

结果：48 个 .vue 文件，0 处使用 v-html 或 innerHTML。Vue3 默认的 {{ }} 自动 HTML 转义。

第二层：后端存储验证

Codex 用已有的用户 token 创建了一个文件夹，文件夹名直接是 XSS payload：

ounter(line<img src=x onerror=alert('XSS_FOLDER')>

文件夹创建成功。查询文件夹列表时，payload 原样返回在 JSON 中。后端不做任何过滤。

第三层：文件上传型 XSS

Codex 找到了一个之前测试中上传的 SVG 文件（含 <script>alert('XSS_SVG')</script>），然后直接构造下载 URL 测试：

• 下载响应：Content-Disposition: attachment（强制下载）
• X-Content-Type-Options: nosniff

所以 SVG 中的脚本无法被浏览器执行。

但这还没完——Codex 又翻了下载逻辑的源码，发现：

“如果 filetype 元数据被设置为 text/html 且请求使用 disposition=inline，浏览器会渲染这个 HTML，脚本会执行。”

虽然当前强制 attachment 兜底了，但这个潜在向量确实存在。

最终 XSS 结论：当前无可用利用链，但缺少 CSP 响应头 + 后端无输入过滤，纵深防御不足。

---

补充审计：还有什么漏掉的？

当我觉得差不多了的时候，我又问了一句：

“除了我提到的这些漏洞，还有其他漏洞需要进行排查吗？”

Codex 没有说”应该没了”，而是启动了一轮全面的补充扫描：

• SQL 注入检查：确认全部使用 GORM 参数化查询 ✅
• 路径遍历检查：文件操作基于 resource_id，不涉及文件系统路径 ✅
• CSRF 检查：发现整个系统没有任何 CSRF 防护
• 速率限制检查：gin.Default() 没有任何 RateLimit 中间件
• SSRF 检查：httpPost 从配置文件读 URL 直接发起请求，无白名单无内网过滤
• 安全响应头检查：CSP、HSTS、X-Frame-Options 全部缺失
• Cookie 安全：secure=false 明文传输，SameSite 未设置
• 审计日志完整性：仅追加但无签名/哈希链

最终又挖出了 5 个新漏洞，全部标注了代码位置、风险等级和修复建议。

---

报告生成：我说”按高中低排序”，它就排好了

最后一步是生成最终报告。我提了几个要求：

1. 漏洞描述、漏洞危害、修复建议、漏洞复现过程四个维度
2. 只包含可以复现成功的漏洞
3. 按高、中、低风险排序
4. 补充审计的新发现也加进去

Codex 直接生成了一份 722 行、26KB 的完整 Markdown 报告，结构清晰：

• 审查摘要 + 统计表格
• 漏洞总览表（19 个漏洞，按严重等级排序）
• 每个漏洞的详细说明（含代码引用和复现命令）
• XSS 专项测试结论
• 管理后台专项测试
• 修复优先级（P0/P1/P2/P3）
• 攻击链全景图
• 补充审计排除项
• 附录（命令速查 + 关键文件清单）

报告中所有的 curl 命令和 JavaScript 代码都是从实际验证中提取的——不是”理论可行”，而是现场跑通过的。

---

1. 它不只是”找答案”，而是”做验证”

Codex 不会停在”代码里看到一行有问题的逻辑”。它会主动构造 HTTP 请求，往真实服务器发，用返回的 HTTP 状态码和 JSON 数据来证明漏洞存在。

2. 一次对话可以同时覆盖代码审计和黑盒测试

传统的安全审计流程是：代码审计 → 整理疑似漏洞 → 黑盒验证 → 写报告。Codex 把这些步骤压缩到了同一个对话里——它边读代码边发 HTTP 请求，边验证边记录。

3. 提出针对性问题比泛泛而问效果好

“有没有 XSS” → Codex 做了三层验证（前端扫描 + 后端存储 + 文件下载），给出了可信度很高的结论。

“还有别的漏洞吗” → Codex 启动了 8 个维度的补充扫描。

4. 时间效率是数量级的提升

| 环节 | 传统方式 | 用 Codex | | — | — | — | | 代码阅读理解 | 1-2 天 | 分钟级 | | 漏洞验证 | 1 天（手动构造请求） | 实时（自动构造+发请求） | | 深入审计 | 2-3 天 | 1-2 小时（对话引导） | | 报告撰写 | 半天 | 几分钟（一次性生成） |

---

怎么开始你自己的审计

如果你也想来一次类似的 AI 辅助安全审计，这是我建议的问法：

第一步：加载上下文

“帮我分析这个项目的安全状况。先读项目结构和关键代码，告诉我架构和鉴权链路。”

第二步：验证已有发现

“这份报告里有几个漏洞，帮我逐个验证它们是否真的存在，用实际的 HTTP 请求来复现。”

第三步：特定维度深挖

“检查一下所有用户输入的地方有没有 XSS、SQL 注入、路径遍历。”

“管理后台的权限校验是否完整？普通用户能不能访问管理接口？”

第四步：补充扫盲

“除了已经发现的，常见的 Web 安全漏洞（CSRF、SSRF、速率限制、安全响应头等）还有哪些存在？”

第五步：生成报告

“把所有确认的漏洞写一份报告，每个按描述、危害、修复、复现过程来写，按严重等级排序。”

---

复盘：这次审计的几个关键感知

---

这次审计最大的收获不是找到了 19 个漏洞，而是体验了一种全新的工作方式——我可以把精力放在”判断”和”决策”上（这个漏洞的风险有多大？下一步应该排查哪个方向？），而把”执行”（读代码、构造请求、写报告）交给 AI。

以前做安全审计像在迷宫里自己走，现在更像坐在监控室里看无人机传回的画面——视野更宽，速度更快，而且不容易漏掉死角。

---

---

最终产出：一份 722 行的专业报告

经过多轮验证、补充、排序，最终的报告长这样：

报告形态：Markdown 文档，722 行，约 26KB

报告结构：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line一、审查摘要          → 一句话说清核心风险二、漏洞总览表        → 19 个漏洞，按严重等级排序的表格三、严重漏洞详情      → 3 个 Critical，含代码引用 + 复现命令 + 修复方案四、高危漏洞详情      → 4 个 High五、中危漏洞详情      → 8 个 Medium（含新增的 CSRF、速率限制、SSRF）六、低危漏洞详情      → 4 个 Low七、XSS 专项测试       → 三层验证结论 + 安全头检查八、管理后台专项      → 权限模型验证 + 越权测试九、修复优先级        → P0/P1/P2/P3 排序的修复路线图十、攻击链全景图      → 可视化攻击路径十一、补充审计排除项  → 确认 SQL 注入/路径遍历等不存在十二、附录            → 命令速查 + 关键文件清单

漏洞成果速览：

| 等级 | 数量 | 典型漏洞 | 验证方式 | | — | — | — | — | | 严重 | 3 | 签名绕过认证、硬编码密钥下载、无认证提权 | HTTP 远程复现 | | 高危 | 4 | 开发模式暴露、回调缺鉴权、凭据硬编码、pprof 暴露 | HTTP + 代码交叉验证 | | 中危 | 8 | CORS 通配、用户枚举、回收站越权、CSRF、速率限制、SSRF 等 | 多方面验证 | | 低危 | 4 | 安全响应头缺失、Cookie 不安全、审计日志等 | 代码审计 |

报告中每一条漏洞都包含四个维度：漏洞描述 → 危害分析 → 修复建议 → 复现过程。所有的 curl 和代码片段都是从实际验证中提取的，任何人照着操作都能复现。

---

另一个值得聊的话题：安全从业者该怎么办？

这篇文章写到这里，其实埋着一个更根本的问题：

如果 AI 能做代码审计、能构造 PoC、能写报告——那安全工程师还干什么？

我的感受是：角色变了，但价值没变，甚至更高了。

AI 接管的是”执行”，不是”判断”

回看这次审计，Codex 帮我做了这些事：

• 读代码、理解架构、找漏洞线索
• 构造 HTTP 请求、发到真实服务器、解析返回结果
• 组织报告结构、按等级排序、输出格式化的 Markdown

但这些东西，我自己也都”会做”——只是做起来太花时间。真正需要我判断的，Codex 替代不了：

• 确认了 12 个漏洞之后，下一步应该深入哪个方向？ 我选择了 XSS 和管理后台，而不是先去查 SQL 注入（因为代码里已经全是 ORM 参数化查询），这个优先级判断来自经验。
• XSS 测试得出的结论是”当前无可用利用链”，这个结论能不能接受？ 我让 Codex 又补了一层 CSP 检查才最终放心。
• 新增的 5 个漏洞里，SSRF 的实际利用需要先拿到配置写入权限，风险等级应该定中危还是低危？ 我结合整体攻击链（vul-005 凭据泄露 → 配置篡改 → SSRF）判断定为中危。

安全人员的核心能力在迁移

以前的安全工程师简历上写着”精通 Burp Suite、熟读 OWASP Top 10、能独立完成渗透测试”。

以后可能要加一条：“能在 50 个疑似漏洞中，用 3 个精准问题找到真正致命的那一个。”

具体来说，能力重心在从”动手”转向”动脑”：

| 传统能力 | AI 时代的能力 | | — | — | | 会用扫描器跑全量规则 | 知道什么时候不需要跑扫描器 | | 能手写 SQL 注入 payload | 能判断 AI 生成的 payload 是否覆盖了边界 | | 能独立完成渗透测试报告 | 能把 AI 生成的 26KB 报告压缩成一页纸给 CTO 看 | | 记住 OWASP 所有分类 | 能在模糊的描述中，提炼出”你其实想问的是 CSRF 对吧” |

所以，可以把时间省下来休息吗？

这个问题分两层回答。

技术上：省下来的时间，应该投向更深层次的思考。

Codex 帮我在一天内做完了一周的活，省下的四天不是用来刷手机的。而是用来问自己：这个系统的业务逻辑里，有没有什么非标准化的攻击面？配额机制的设计有没有竞态条件？多租户隔离是不是真的隔离了？

这些都是 AI 目前还做不到的——它能在已知的模式里高效工作，但发现新模式、提出新假设、推翻旧假设，还是人的主场。

生活上：应该。

安全行业长期处于”人手不够、时间不够、永远在赶工”的状态。AI 如果能把这个状态缓解——哪怕只是让一周的审计变成三天——那就意味着你可以在周二晚上关掉电脑去吃顿好的，周末不用抱着笔记本在咖啡馆里挖洞。

这不是偷懒，这是把人的精力还给人的生活。一个休息充分的安全工程师，比一个连续加班三周的，更容易发现那个藏在角落里的致命漏洞。

---

这次审计最大的收获不是找到了 19 个漏洞，而是体验了一种全新的工作方式——我可以把精力放在”判断”和”决策”上（这个漏洞的风险有多大？下一步应该排查哪个方向？），而把”执行”（读代码、构造请求、写报告）交给 AI。

以前做安全审计像在迷宫里自己走，现在更像坐在监控室里看无人机传回的画面——视野更宽，速度更快，而且不容易漏掉死角。

而下一个问题是：当无人机飞得越来越好，坐在监控室里的那个人，应该把目光投向哪里？

---

本文基于真实的安全审计项目撰写。所有漏洞编号、代码位置、复现命令均来自实际验证结果。

工具：Codex（OpenAI）审计对象：某企业网盘系统审计日期：2026-06-18

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：句芒安全实验室 句芒安全实验室 句芒安全实验室《Codex安全审计实战》