这个世界有猫饼如果你打开一个网址，习惯性地往 URL 后面多加了几个字符，页面就把 flag 直接吐了出来，这种体验在刚接触 CTF Web 题时非常常见。Bugku 平台上这道 GET 题就是这样：逻辑简单到几乎没有绕弯，只要你猜到参数值，就能直接拿到 flag，全程没有任何权限验证。它适合刚入门的选手熟悉 HTTP 请求结构，也适合从做题转向写代码的人思考一个问题：为什么一个仅仅“猜参数值”的操作，就能突破一道本应有防护的关卡？
这篇文章我会从实际做题过程讲起，还原一次完整的参数猜解流程，再把这层“猜参数值”的技术外衣剥掉，聊聊它背后缺失的权限验证到底是什么。最后我会落到真实开发场景中，给出同类型接口漏洞的几种常见写法、修复方式，以及后续可以继续练习的方向。无论你是 CTF 新手，还是写过几个 Web 项目的开发者，这篇文章应该都能提供一些值得带走的东西。
1. 从一道 Bugku 的 GET 题说起：没有权限验证的入口意味着什么
1.1 第一次打开题目时的直觉判断
这道题在 Bugku 平台上的页面非常简单，没有复杂的交互界面，没有输入框，也没有跳转逻辑。打开之后就是一个平平无奇的页面，甚至乍一看都不知道该做什么。像我这种习惯先看“入口在哪”的人，第一反应就是按 F12，先把浏览器开发者工具开出来，看看请求长什么样。
这里有个做 Web 题的基本功：不要只盯着肉眼看到的页面，要看浏览器到底发出去什么请求、服务器返回了什么响应。 页面长得再简单，请求和响应里往往藏着关键信息。这道题打开开发者工具后能看到，整页只有一个普通的 GET 请求，URL 路径很干净，没有带任何查询参数，响应回来的 HTML 也没有明显异常。那问题就很清楚了：服务器端肯定隐藏着某个逻辑，只有当你往 GET 请求里加入正确参数时，它才会触发。
这类题目在 CTF 里被归为“逻辑漏洞”，说白了很多时候就是后端代码写得太随意——没有身份校验、没有会话管理、没有权限分级，只要请求参数猜对了，它就把 flag 给你。这也是我标题里提到“逻辑简单，猜到参数值就能直接获取 flag”的原因。
1.2 这类题为什么适合入门
简单并不等于没价值。这道题的考点很集中：GET 请求的参数传递机制。你要知道 URL 中问号后面是查询字符串，查询字符串由“参数名=参数值”组成，多个参数之间用 & 连接。如果你的 URL 里没有参数，那就是在告诉服务器“我只请求这个路径本身”。而这道题恰恰需要你去输入参数。
我见过不少初学者卡在第一步，原因不是不懂技术，而是不知道题目在问什么。这类题目的好处就是帮助你建立“做题思路”：服务器代码我看不到，但它一定有一个判断逻辑，比如 if ($_GET['key'] == 'flag')。我要做的就是通过尝试，把这个判断条件“喂饱”。
基础概念理清了，后面实操起来才不会慌。接下来我带你完整走一遍我的猜解过程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 一次完整的解题过程：我是怎么把 flag 问出来的
2.1 第一步：在页面和响应里找线索
按 F12 打开开发者工具，切到 Network 面板，刷新页面，能看到一个文档请求。点开这个请求，你会发现 Headers、Preview、Response 这些标签页。这里我建议先看 Response，也就是服务器返回的原始 HTML。
很多时候，出题人会在 HTML 注释里留线索。比如：
html复制<!-- hint: try to find the flag parameter -->
这就是在明示：参数名可能就叫 flag。还有的情况是网页里有一段 JavaScript，里面定义了一个变量但没有用到，或者某个接口地址写在隐藏的 input 标签里。总之，响应内容不能只看渲染后的页面，要看源码。我在这道题的响应内容里找到的线索是指向“某个参数名”的提示，具体就不再剧透更多了，因为留点悬念给还没做的人更有意思。
如果你发现响应里什么线索都没有，那就进入下一步：猜。猜参数是 Web 题里绕不开的能力，尤其在参数名比较常规的情况下。
2.2 第二步：构造参数名与参数值的猜解清单
猜参数不能瞎猜，需要积累一套常见的“口令表”。拿这道题来说，既然提示是 GET 且与 flag 直接相关，那优先尝试的参数名一般有这些：
| 参数名方向 | 常见参数名示例 | 对应的后端判断逻辑 |
|---|---|---|