碰客户 API 之前，先学完这门免费安全课

Web Security Academy 的部分认证实验会给你一份候选用户名和密码清单，任务是：找出真实账号并登录。亲手攻破一个看上去再普通不过的登录表单，这种体验是任何幻灯片都替代不了的。

这门课由 Burp Suite 背后的公司 PortSwigger 出品。PortSwigger 称其为 Web 应用安全的在线培训中心，并表示它 100% 免费。课程内容来自 PortSwigger 的研究团队，以及《The Web Application Hacker’s Handbook》的作者 Dafydd Stuttard。

这对前线部署工程师（FDE）很重要，因为你的工作就是连接系统：调用客户的 API，为演示搭一个登录页，编写能自己抓取链接的 Agent。

每一项都多开了一道入口。与其等客户的安全团队在你的代码里找到漏洞，不如先在一个允许你攻破的系统上练习攻击。

是实验室，不是教科书

2026 年发布的一份入门指南统计，这个学院共有 31 个专题、数百个实验，分为三个难度：Apprentice、Practitioner 和 Expert。

PortSwigger 把自己的实验描述为贴近真实的谜题，用来检验你作为攻击者的能力。注册账号后可以跟踪进度，从 Apprentice 一路升到 Expert，并在名人堂（Hall of Fame）查看排名。

自 2023 年 9 月起，学院推出了学习路径，即预先规划好的路线，避免新手在众多专题中迷路。最早上线的两条是服务端漏洞概览和 SQL 注入。

据同一份指南，免费的 Burp Suite Community Edition 足以完成大部分实验；只有需要 Collaborator 的实验和认证考试才要求 Professional 版。

一位通过 OSWE 的人在评测中写道，这些实验几乎覆盖了所有常见漏洞，并认为学院是正式课程的绝佳补充。不过实验库这么大，FDE 不必全部做完。其中有三个思路最值得记住。

思路一：你的 API 接收的参数比你以为的多

API 测试专题聚焦 RESTful 和 JSON API，涵盖三部分内容：通过 API 文档做侦察、批量赋值，以及服务端参数污染。PortSwigger 提醒，批量赋值（也叫自动绑定）可能在无意中产生隐藏参数。

假设你写了 PATCH /api/users/me，让客户的员工修改邮箱。框架把整个 JSON 请求体直接绑定到用户对象上。用户只要多发一个 "role": "admin"，就能给自己提权，尽管 API 文档从未提到这个字段。

有漏洞的代码和加固后的代码，往往只差几行：

# 修改前：把整个 JSON 请求体绑定到模型
user.update(**request.json)  # 多发一个 "role": "admin" 也能通过

# 修改后：只接收允许的字段
ALLOWED_FIELDS = {"email", "display_name"}
data = {k: v for k, v in request.json.items() if k in ALLOWED_FIELDS}
user.update(**data)

到客户现场的第一件事：为每个写入数据的端点列出允许接收的字段，其余一律拦截。另外，也值得用做侦察的人的眼光，把你发布的 API 文档重读一遍。

思路二：登录 bug 就是安全 bug

认证专题强调，认证漏洞会让攻击者拿到敏感数据和功能。其中很多实验要求你先枚举用户名，再暴力破解密码。而在赶着为试点项目搭登录门户时，这里也最容易出错。

举个简单的例子：登录表单在用户名错误时返回“账号不存在”，在密码错误时返回“密码错误”。

光凭这两条不同的提示，攻击者就能筛出一份真实账号清单，再逐个集中猜密码。修复方法是把两个分支合并成同一个响应：

# 修改前：两条不同的提示，暴露了哪些用户名存在
if user is None:
    return error("账号不存在", 404)
if not check_password(user, password):
    return error("密码错误", 401)

# 修改后：所有失败看起来完全一样
if user is None or not check_password(user, password):
    return error("用户名或密码错误", 401)

所以在交付演示之前，要让每次登录失败都返回相同的提示和相同的状态码，并限制尝试次数。

思路三：能抓取 URL 的 Agent 是 SSRF 的入口

服务端请求伪造（SSRF）指攻击者诱使服务器代替自己发出请求。PortSwigger 写道，SSRF 攻击一旦成功，往往会导致组织内部的未授权操作或数据访问。

对做 AI 的 FDE 来说，这是三个思路中最重要的一个。设想你给 Agent 一个在客户内网运行的 fetch_url 工具。只需一条措辞巧妙的提示词，让它读取某个内部服务的地址，Agent 就会乖乖把数据带出去。Webhook 和“从链接导入数据”功能也有完全相同的风险。

怎么做：写一份工具允许调用的域名清单，屏蔽内部地址段，并在客户安全团队开口之前就写进设计文档。

糟糕的修复比不修更糟

最容易掉进去的陷阱，是用黑名单代替白名单。给 fetch_url 工具禁掉 localhost 和几个内部 IP 段听起来够了，但黑名单只要漏掉一种地址写法就会泄露。

白名单要严密得多，但也并非滴水不漏。一个存在开放重定向的允许域名，依然可以把请求转到内部地址；DNS 重绑定也能让域名在你检查之后指向另一个 IP。

所以要在解析之后、即将建立连接之前再检查一次 IP，并且要么关闭自动跟随重定向，要么把每一跳重定向当作新请求重新检查。

批量赋值也一样。如果只拦截 role 字段，一旦模型新增了敏感字段而没人记得更新黑名单，端点就又暴露了。

下一个陷阱是只按 IP 限制登录尝试。攻击者换个 IP，这个限制就形同虚设，所以还要按账号统计失败次数。合并错误提示之后，也要检查状态码，确保两种失败情况真的完全一致。

按什么顺序学，简历上写什么

这门课适合有几年经验、熟悉后端代码、但从没站在攻击者角度看过系统的工程师。先学服务端漏洞学习路径，再学认证，然后是 API 测试，最后是 SSRF。每个专题内，先做完 Apprentice 实验再进入 Practitioner，Expert 实验留到以后。

Burp Suite Certified Practitioner（BSCP）是官方认证，但属于可选项，需要付费，还要求有效的 Burp Suite Professional 订阅。只有瞄准安全色彩很重的 FDE 岗位时才值得去考。

简历上不要只写“懂 Web 安全”。要具体写明完成了哪些 API、认证和 SSRF 方向的 Practitioner 实验，再附一篇简短的复盘，讲你如何加固一个 Agent 工具来防御 SSRF。

在 Agent 设计面试中，赶在面试官提问之前主动谈到白名单、解析后 IP 检查和重定向处理，是一个非常清晰的信号。

客户不会问你解了多少个实验。他们会问你的集成是否安全，而最可信的回答，是你亲自在一个允许攻破的系统上验证过的回答。