文章总结： 本文记录了作者在第三届数信杯中的经历，指出当前AI安全赛题常存在Web漏洞或逻辑缺陷。在模型防御题中，作者利用平台泄露的测试集数据，放弃了复杂的剪枝脱毒操作，转而通过构建相同网络结构并进行过拟合训练，成功获取Flag。文章反思了AICTF中概念错位与Web漏洞喧宾夺主的现象，呼吁更多贴近真实大模型攻防场景的挑战。 综合评分： 88 文章分类： CTF,AI安全,WEB安全,漏洞分析,实战经验

当 AI 安全赛变成了 Web 捡漏局：第三届数信杯参赛思考与“模型防御”题的非预期解

枇杷哥

黑伞安全

2026年1月7日 12:00 北京

一、 AI 安全比赛的“水土不服”

现在的 AI CTF 出题似乎陷入了一个怪圈：出题人懂 AI 但不懂安全，或者懂 Web 安全但不懂 AI。这就导致了题目往往处于一种割裂状态。团队的师傅说这种题简直随便出，大模型从 0 到有的过程就能无限出题，贴上安全的外衣即可。

1. 对抗生成？不，是 F12 大法

比赛中有一道“AI 审计邮箱”的题目，题目描述极其唬人：由于后端集成了“合规审计系统”和“自动登录助手”，你需要构造特殊的邮件内容，既要绕过审计系统的敏感词拦截，又要让自动登录助手识别出其中的账号密码。

作为一个 AI 安全研究者，看到这种题目，我的 DNA 动了。这显然是在考LLM 的指令遵循与防御绕过吧？于是我拿出了打学术界 SOTA（State of the Art）的劲头，构思了一套极其复杂的组合拳：

• 隐写术：我尝试将敏感凭证伪装成正常业务数据，试图欺骗 embedding 层；

• 时间编码：创造性地利用时间戳格式作为载体，赌 AI 难以识别这种非自然语言的模式；

• 分散编码：将账号密码碎片化分散在全文各处，降低注意力机制的集中权重；

• 上下文伪装：甚至把所有编码都嵌入到一份专业的系统运维报告格式中，试图用权威语气进行上下文伪装。

结果呢？全、部、被、拦。那个审计 AI 就像个毫无感情的关键词匹配机器，任凭我把 Prompt 写出花来，它就是死活不认。

就在我怀疑人生，以为碰上了什么黑科技防御时，我甚至开始怀疑是不是思路太复杂了。百无聊赖中，我按下了F12，打开了开发者工具。

那一瞬间，我沉默了。我对着屏幕笑了：这不是 AI 安全，这是前(故)端(意)开(设)发(计)事故。

2. Pickle 反序列化：时代的眼泪

另一道稍微沾边的题考察的是 pickle 反序列化。对于打过传统 CTF 的人来说，这属于“送分题”。Python 的 pickle 模块由于其不仅序列化数据还序列化指令的特性，天生就不安全，参考CVE-2024-3568。思路上确实可以刷漏洞，打一下 SRC 也是有可能的。不过现在的模型权重大多都在向 safetensors 迁移，所以就趁年轻抓紧刷洞吧。（我自己出题也爱出这种…)

二、 降维打击：第八题“模型防御”的非预期解

第八题“神经元剪枝脱毒防御”则是一个典型的“设计失误导致逻辑崩塌”的案例。

1. 题目本意：高大上的剪枝与脱毒

根据任务书描述 ，这道题的背景设定非常宏大：

• 场景：深度神经网络在资源受限环境下的部署。

• 问题：模型中存在“投毒”结构（恶意或冗余神经元）。

• 任务：利用平台提供的可视化工具进行剪枝（Pruning），在保持准确率（95%以上）的同时去除毒性 。

• 机制：题目给了一个predict.py定义模型结构，以及一个model.pth权重文件 。

按照出题人的预期，选手应该去分析神经元的激活值，通过可视化面板找到那些对输出贡献异常或者不重要的神经元，手动或自动切断连接。这是一个典型的模型优化与可解释性问题。

2. 破局点：从黑盒防御变成白盒拟合

然而，当我打开“模型性能评估”页面时，一切都变了。

平台为了方便选手查看“误差”，竟然直接展示了测试集的详细信息，并且——支持导出 CSV。 我下载了 CSV 一看，里面完整包含了 200 条测试样本的输入(x1, x2, x3)和真实值。

Critical Thinking 时刻：

• 传统思路：上传模型 -> 平台用私有测试集打分 -> 分数不够 -> 修改剪枝策略 -> 重试。（黑盒优化）

• 非预期思路：既然你把“考卷答案”都给我了，我为什么要学“剪枝”？我直接背答案不就行了？

这瞬间从一个复杂的“模型剪枝脱毒”问题，退化成了一个最基础的“已知 200 个数据点的过拟合（Overfitting）”问题。我不关心模型有没有毒，我只关心我的输出能不能完美拟合这 200 个 y_true。

3. 技术实现：暴力过拟合

既然决定了走非预期解，剩下的就是写代码了。

第一步：复刻模型结构 从题目提供的predict.py中，我们可以直接看到官方的模型架构 ： 一个简单的 5 层全连接网络（3 -> 32 -> 24 -> 16 -> 8 -> 1），层间使用 ReLU 激活。

第二步：构建“作弊”训练集 直接读取从平台下载的 CSV 文件，将这 200 条测试数据作为我们的训练集。

第三步：针对性训练 这里的核心策略是放弃泛化能力，追求极致的记忆。

• Loss Function：使用SmoothL1Loss，对回归任务友好且稳定。

• Epoch：直接拉满到 8000 轮甚至更多，直到 Loss 接近于 0。

• 无验证集：不需要验证集，因为我们的目标就是“过拟合”这 200 条数据。

代码核心逻辑如下（完整代码略）：

# 定义与官方 predict.py 一致的模型
class SimpleRegressionModel(nn.Module):
    def __init__(self):
        super().__init__()
        self.fc1 = nn.Linear(3, 32)
        # ... (中间层略)
        self.fc5 = nn.Linear(8, 1)
        self.relu = nn.ReLU()
    # ... Forward 逻辑略

# 加载“泄露”的测试集
dataset = CSVDataset("test_data_leaked.csv") # 200条数据
# 疯狂训练
for epoch in range(8000):
    pred = model(x)
    loss = loss_fn(pred, y)
    loss.backward()
    optimizer.step()

4. 结果

将本地训练好的（严重过拟合的）model.pth上传。 平台原本用来评估泛化能力的测试集，此刻已经被我的模型完全“背诵”下来了。 匹配率：100%（或接近）。 系统判定通过，直接弹出 Flag 。

所谓的“剪枝”、“脱毒”、“可视化分析”，统统没有用到。

三、 对当前 AI 安全 CTF 的反思

这次比赛的经历，其实折射出当前 AI 安全领域竞赛的两个尴尬现状：

1. 概念错位：很多主办方认为 AI 安全 = AI 算法题。其实真正的 AI 安全更偏向于 System Security for AI（如模型文件解析漏洞、推理框架漏洞）或者 AI Specific Attacks（如提示词注入、对抗样本）。像这种单纯考“剪枝”的题，更像是算法岗的面试题，而非 CTF 题。

2. Web 漏洞喧宾夺主：这是最致命的。题目想考 AI，结果环境本身存在逻辑漏洞（如本题的数据集泄露）或 Web 漏洞（F12、SQL注入等）。当解题的最短路径变成了 Web 渗透时，这道 AI 题就失败了。

对于我们这种想在 AI 安全领域深耕的从业者来说，我们渴望的是更贴近真实大模型攻防场景的挑战——比如如何在黑盒状态下通过 API 逆向出 Prompt，或者如何构建特殊的 payload 绕过大模型的对齐机制。

希望未来的比赛能少一点“Pickle”，少一点“F12”，多一点真正的Adversarial Intelligence。

本文仅代表个人参赛观点，技术交流使用。

免责声明：

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

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

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

本文转载自：黑伞安全 枇杷哥《当 AI 安全赛变成了 Web 捡漏局：第三届数信杯参赛思考与“模型防御”题的非预期解》