第一次接触 ctfshow 的 web 入门，web1 这道题往往被很多人当成“有手就行”。可实际情况是，不少新手打开页面之后盯着屏幕发呆，不知道该点什么，也不知道 flag 到底藏在哪里。我当初第一次做这道题也是这样，后来才发现它考的根本不是多高深的技术，而是一个非常基础的意识：你会不会把一个普通网页翻个底朝天。这篇文章就把 ctfshow【web入门】web1 的完整思路拆开讲，从打开页面到拿到 flag，再到后边遇到类似题目的排查套路，都会覆盖到，希望给你一个能直接照着操作的起点。
1. 拿到题目先别急：先弄懂 web1 这道题到底想考什么
1.1 题目特征与考点分析
ctfshow 的 web 入门题目编号很多，web1 是最基础的一道。它一般不会给你一个复杂的后台系统，也不会让你去猜域名、爆破路径，而是直接给一个简单的 URL，页面可能只有一句话。没做过 CTF 的人会觉得莫名其妙，做过的人就懂，这种题的答案往往藏在最容易被看见的地方：页面源代码。
很多刚开始接触安全的人会陷入一个误区，觉得 Web 题一定需要“攻击”什么。实际上，CTF 是 Capture The Flag 的缩写，核心目标是找到一串被称为 flag 的字符串。这串字符串可能以flag{...}的形式出现，也可能叫ctfshow{...}，但不管叫什么，它本质上就是一道题的答案。出题人会把它放在某个文件、某段代码、某个请求响应里，选手要做的不是爆破，而是通过观察和分析把它找出来。
web1 的考点就是“信息收集”。出题人希望你学会用最基本的工具去查看一个网页的内部结构。这个考点听起来简单，但却是所有 Web 安全方向的基础，因为不管以后做 SQL 注入、文件包含还是反序列化，第一步永远都是搞清楚目标页面到底由哪些元素组成，哪些点是可控的，哪些地方藏着开发者的疏漏。
1.2 做这道题需要准备什么
做 web1 只需要一个浏览器，Chrome、Edge 或者 Firefox 都行，我个人强烈建议用 Chromium 内核的浏览器，它的开发者工具比较好用，而且社区资料多。你不需要装扫描器，不需要在终端敲命令行，更不需要会写脚本，重点是会用 F12 打开开发者工具，会用 Ctrl+F 搜索关键词。
这里有一个很容易被忽略的细节：如果你用的是某些国产浏览器的兼容模式，记得切到“极速模式”。以前我遇到过一个朋友，页面在兼容模式下渲染异常，源码结构和他看到的根本对不上，折腾半天才发现是浏览器内核的问题。极速模式下的开发者工具才完整，也更容易定位问题。
另外，建议准备一个记事本或者笔记软件。把访问过的 URL、页面上的提示、看到的可疑内容都记录下来。别小看这个习惯，后边题目一旦复杂起来，记录比脑子可靠。很多做渗透的老手都有随手记笔记的习惯，因为一次测试往往会涉及几十个请求，只看不记很容易漏掉关键信息。
1.3 为什么第一题不需要上 Burp Suite
很多新手一上来就装 Burp Suite，想抓包看流量。这个工具确实是 Web 安全测试的常备武器，但做 web1 的时候基本用不上。原因很简单：页面本身没有复杂的交互逻辑，所有需要的信息在浏览器开发者工具里就能看到。提早装 Burp 反而容易让你忽略浏览器自身的调试能力，而且 Burp 的证书安装、代理设置对新手来说又是一道坎。
我见过不少人在 web1 上浪费了大量时间，不是题目难，而是他们还没学会走路就想跑步。Burp 是后面学习抓包、改包、重放请求时才需要的工具。web1 这个阶段，把浏览器开发者工具用熟，比装十个工具都重要。浏览器本身就集成了元素检查、网络请求查看、本地存储查看、控制台调试等功能，足够处理入门级的 Web 题。
2. Web 入门的第一个基本功：把整个页面翻个底朝天
2.1 为什么“看源码”是第一优先级
在 CTF 的 Web 题里，网页的本质是 HTML、CSS 和 JavaScript。用户在浏览器里看到的一切，都是这些代码运行后的结果。开发者在写页面的时候，会在代码里留下注释、隐藏的节点、调试信息、甚至临时的测试代码。这些信息不会显示在页面上，但它们确实存在于源码里。
我经常用一个生活化的类比：你到一个朋友家去找一把钥匙，表面上看客厅很整洁，但钥匙很可能在沙发缝隙、窗帘后面、花盆底下。你第一反应应该是翻沙发，而不是直接上撬锁工具。对 Web 题来说，“翻沙发”就是查看页面源代码。
很多题目甚至会把 flag 直接写在 HTML 注释里，比如<!-- flag{hello} -->。你如果不打开源代码，光盯着页面看一辈子也看不到。这个套路虽然简单，却在很多入门题和部分进阶题里反复出现。所以不管你信不信有用，打开目标页面后的第一个动作，都应该是查看它的源码。
2.2 开发者工具的“元素”面板到底怎么用
在页面上点击右键，选择“检查”，或者直接按 F12，就能打开开发者工具。默认会看到“元素（Elements）”面板。这个面板展示的是当前页面 DOM 结构的实时状态，页面上的任何元素，包括没有显示出来的内容，都会以标签节点的形式出现在这里。
关键技巧是：不要用肉眼在元素树里一层层翻。你只需要在元素面板里点一下，确保光标处于当前页面环境中，然后按 Ctrl+F 搜索flag。如果源码里有包含flag关键词的内容，浏览器会自动高亮并跳转到对应位置。我见过太多人打开开发者工具之后只会用滚轮，然后说“找不到”。其实答案就在那里，只是忘了搜索。
这里还要区分两个容易混淆的入口：右键菜单的“查看页面源代码”和 F12 的“元素面板”。前者看到的是服务器返回的原始 HTML 文本，后者看到的是浏览器解析后的 DOM 节点。对于 web1 这种题，两个入口都可能看到 flag。但元素面板更方便定位，因为它会同步展示标签结构、子节点、样式和属性，而且可以结合搜索框直接跳转。
2.3 常见的 flag 隐藏位置清单
学习 web1 的时候，建议顺手记住一张“藏 flag 位置”的清单。以后遇到更复杂的 Web 题，这张清单会越来越有用。
| 隐藏位置 | 典型特征 | 查看方法 |
|---|---|---|
| HTML 注释 | <!-- flag{...} --> | 源码或元素面板里 Ctrl+F 搜索flag或!-- |
| 隐藏标签 | <div style="display:none"> | 元素面板里展开节点，查看 style 属性和子内容 |
| JavaScript 变量 | 代码中出现var flag='...' | 搜索flag，或在控制台里输入变量名 |
| Cookie | 请求头或 Set-Cookie 中存在可疑字段 | 网络面板或 Application 面板查看 |
| localStorage / sessionStorage | 存储中的 key 名为 flag | Application 面板左侧 Storage 分类查看 |
| 响应头 | 自定义字段如X-Flag: flag{...} | 网络面板点击文档请求，查看 Headers |
| robots.txt | Disallow: /flag.txt | 直接访问/robots.txt，再访问对应路径 |
这张表不需要背，但每一条都应该亲手试一次。做题的时候，先按表里的顺序排查，大概率不会漏掉 flag。
3. 实操复现：ctfshow web1 从访问到拿 flag 的完整流程
3.1 第一次访问页面时，先观察什么
拿到题目给的 URL 之后，不要立刻按 F12。先在浏览器里正常访问一次，看看页面的主题、文案、有没有跳转链接、有没有输入框、有没有登录要求。这个过程非常重要，因为后面所有操作都要基于“页面原本长什么样”来做判断。
举个例子，假如页面显示一句话，大概意思是欢迎来到某个平台的挑战题，除此之外什么都没有，那基本可以断定 flag 就在源代码或者网络响应里。这时候不需要猜注入点、不需要扫描目录，老老实实做最基础的“查看源代码”就好。
观察的时候还要注意地址栏。URL 里的参数，比如?id=1、?name=admin，都是潜在的可控点。web1 可能不会涉及到后续利用，但你现在应该培养起“看到参数就多想一想”的习惯。参数越多，说明后端的处理逻辑越复杂，题目空间也就越大。
3.2 F12 三步定位 flag
第一步，在页面空白处点击右键，选择“检查”，或者直接按 F12。这时候浏览器下方或右侧会弹出开发者工具。第二步，确认当前处于“元素（Elements）”面板，然后按 Ctrl+F，输入flag。第三步，看高亮结果。
如果命中了一个注释，那么注释里那串字符很可能就是最终答案。复制的时候注意不要复制多余的空格、尖括号和换行符。我见过有人把<!--也复制进去，提交当然不成功。
这里还有一个很实用的土办法：如果第一次搜索flag没有结果，就搜索ctfshow，这是平台的名字，很多题目会在变量名、注释或者隐藏字段里带上平台标识。再不行，直接搜索{和}。这两个花括号在正常的 HTML 元素里极少成对出现，一旦在注释或字符串中出现，很有可能是 flag 的一部分。这个方法听起来有点笨，但我在复盘很多简单题时发现，它确实能救命。
3.3 提交 flag 的细节
找到 flag 之后，回到 ctfshow 的题目页面，在提交框里输入那串内容。注意格式通常是flag{...}，大小写完全一致，括号也是英文半角。有些题目要求只提交花括号中的内容，有些要求包含整个flag{}，具体以页面提示为准。如果不确定，就把格式完整贴进去，一般不会错。
提交成功后会有一个明显的成功提示，页面可能自动刷新，并且把这道题标记为已解决。没成功的话，优先检查两件事：一是 flag 字符串有没有复制完整，二是格式有没有问题。不要急着怀疑题目或者平台出错，大多数失败都是自己粗心导致的。
我做完题之后会顺手把解题过程整理成笔记，格式大概是这样的：题目编号、目标 URL、使用了什么方法、在哪里发现 flag、flag 是什么。这个习惯不是一次两次有用，而是长期有用。你后面会遇到越来越复杂的题目，需要反复对比曾经的处理思路，笔记就成了你的私人知识库。
4. 如果没找到 flag？从 web1 延伸到 Web 题的通用排查套路
4.1 把目光从 HTML 源码转移到网络面板
有时候 flag 不在页面代码里，而是藏在服务端返回的响应里。打开开发者工具的“网络（Network）”面板，刷新一下页面，你会看到一堆请求，包括文档、脚本、样式、图片等。点击最上面那个文档请求，然后看“响应（Response）”和“响应头（Headers）”。
很多题目会在响应头里放自定义字段，比如X-Flag: flag{xxx}，页面和源码里都看不到，只有看网络面板才能发现。这个操作我建议做 Web 题的时候每次都看，哪怕题目很简单，也顺手点一眼响应头。因为出题人喜欢利用“选手只盯着正文看”的盲区。
另外，Cookie 也是一个经常被忽略的位置。Cookie 的查看方式有两种：一种是在网络请求的请求头里看Cookie字段，另一种是切到开发者工具的“应用/Application”面板，在左侧找到 Cookie 分类，直接看当前站点存了哪些键值对。如果某个 cookie 的 key 叫 flag，或者 value 长得像一串编码后的文本，就要留意。
4.2 robots.txt 和其他隐藏文件
Web 入门的题目很喜欢考 robots.txt。这个文件本来是用来告诉搜索引擎哪些路径不能抓取的，但 CTF 出题人经常在里面写一个隐藏路径。比如说Disallow: /flag.txt，看到之后，你直接访问/flag.txt这个路径，就可能看到 flag。
所以，当页面源码和网络响应里都没有答案时，可以尝试访问一些常见路径：/robots.txt、/.git/、/www.zip、/backup.sql、/admin等。我把它们称为“默认字典路径”，因为很多开发者会留下备份文件、后台入口或者调试信息。web1 大概率用不上这么深，但知道 robots.txt 这一条已经足够。
需要注意的是，所有操作都必须在 CTF 平台给定的目标环境中进行。CTF 平台提供的靶机本来就是练习环境，探索它没有问题，但绝对不要把同样的方法用到未经授权的真实网站上。安全测试的边界意识，应该从第一道题就开始培养。
4.3 尝试带参数请求与简单交互
如果页面上有一个输入框，或者 URL 里带着?id=1这样的参数，你可以尝试修改参数值，观察页面返回是否发生变化。比如把?id=1改成?id=2，看看页面显示的内容是不是不同。如果页面提示“不存在”或者报错，那说明后端确实在根据这个参数做一些查询操作。
这个阶段的“改参数”不叫真正的攻击，更像是在试探一个对象的开关。你按下一个开关，看有什么反应；再按下另一个开关，又有什么反应。通过这个方式，你能快速了解页面背后到底接了什么逻辑。web1 通常不会要求走到这一步，但把这个习惯养成，后面做 SQL 注入时会非常受益。
其实 SQL 注入的起点，就是发现某个参数会影响后端的查询结果。就像你在门外敲门，听到里面有回声，就说明屋里有空间。当你确定一个参数可控时，才会去考虑怎么构造恶意数据。而这些判断能力，都是从最简单的“改一改参数看反应”开始的。
5. 新手做 Web 入门题最容易踩的五个坑
5.1 坑一：打开了开发者工具，却不会搜索
这个坑特别普遍。很多新手按了 F12，但注意力只放在“元素”面板的节点树上，一层层展开、一层层找，眼睛都看花了也找不到 flag。其实你只需要用 Ctrl+F 搜索关键词，开发工具会直接帮你定位。网页工具不是给你拿肉眼看的结构图，而是可以当作文本搜索器来用的。
我见过有人在一个几十行的 HTML 源码里手动翻了三分钟，最后说“这题没有 flag”。实际上旁边搜索框里输入flag，结果就在第一行。这种失误完全是可以避免的。
5.2 坑二：混淆了“查看源代码”和“元素面板”
右键点击页面后，有一个“查看页面源代码”的选项，还有一个“检查”。前者打开的是一个纯文本页面，显示服务器返回的原始 HTML；后者打开的是开发者工具，展示的是 DOM 树。有些题目的 flag 藏在 JS 动态生成的内容里，普通源码里看不到，但元素面板能看到；反过来，如果 flag 写在 HTML 注释里，两个入口都能看到。
所以建议两个入口都试一遍。先右键查看源代码，再按 F12 看元素面板，每次搜索flag和ctfshow。不要只依赖其中一个，因为你不知道出题人把答案藏在了哪一层。
5.3 坑三：搜索关键词不够全面
只搜flag确实是最常见的做法，但有时候出题人会故意把关键词改成大写FLAG，或者用平台名ctfshow，又或者用key、pass、data之类的词。如果你只搜flag，可能什么都搜不到。这时候要灵活一点，把关键词换成大小写变体、平台名、常见提示词，甚至直接搜{或}。
还有一种情况是 flag 被拆成了两段，一段出现在注释里，另一段出现在控制台输出里。只搜某一个关键词时只能看到一半，需要把两段信息关联起来。所以做题时不要满足于“找到一个可疑字符串”，最好把页面所有可疑的地方都看完，形成一个整体判断。
5.4 坑四：急于使用扫描工具
刚入门时最容易迷信扫描器，想着扫一下目录、扫一下端口就能一步到位。其实对 web1 这种题，扫描器大概率扫不出任何有意义的东西，反而浪费时间，还可能把题目环境搞得很乱。第一题考察的核心是浏览器基础操作，不应该用工具绕过。
先手动把信息收集练熟，再考虑 Dirsearch、Nmap 这些工具也不迟。而且手动收集的过程能帮助你理解工具背后的原理。等你清楚知道“为什么要扫目录”之后，再用工具就会事半功倍。
5.5 坑五：提交 flag 时粗心大意
复制 flag 的时候，把空格、换行、引号一起复制进去，或者少复制了一个花括号，提交就会失败。这种问题非常打击人，但确实经常发生。我现在的做法是先把 flag 粘贴到一个记事本里，肉眼检查一遍，确认没有多余字符，再复制到提交框。多花十秒钟，能省掉很多无意义的重复提交。
另外一个常见问题是，把flag{写成flag｛，也就是英文括号变成了中文全角括号。这属于肉眼很难分辨的字符错误，但只要在记事本里仔细看，还是能发现的。格式严格是 CTF 的基本要求。
6. 做完 web1 之后，下一步应该怎么走
6.1 从第一题建立自己的 Web 题操作清单
这道题让我最有收获的，其实不是那个 flag，而是“操作路径”。访问页面、查看源代码、搜索关键词、看网络响应、看本地存储，这就是一份最小的 Web 题排查清单。以后每做一道新题，我都会在这份清单上不断追加新项目，比如看 robots.txt、查看 JS 文件、测试参数、尝试修改请求方法等。
建立清单的好处很明显：遇到完全陌生的题目时，至少不会大脑空白。你会按照顺序去排查，而不是东点一下西点一下，最后什么结论都得不到。这种“方法论”比单个题目的答案值钱得多。
6.2 后续延伸：从 web1 到 SQL 注入、命令执行
Web 入门题会一步一步加深。web1 可能只是看源码，后面的题目会逐渐引入请求逻辑、参数查询、登录绕过、文件上传等概念。再往后，就会出现 SQL 注入、XSS、文件包含、命令执行这样的经典方向。
虽然 web1 没有让你写任何攻击载荷，但它的核心思路会贯穿所有题目。以 SQL 注入为例，第一步依然是观察页面，找到可控参数；第二步是在输入点提交一个单引号，观察页面是否报错；第三步才是尝试闭合、注入查询、读取数据。你会发现，后面这些操作的起点，还是在 web1 里学会的“打开网络面板，仔细阅读每次请求和响应”。
所以不要把 web1 当成一个“做对了就走”的签到题。它更像一扇窗，通过它你第一次看到 Web 页面背后还有那么多看不见的东西。你现在花时间搞懂它，后边学任何 Web 漏洞都会顺畅很多。
6.3 最后分享一点个人体会
我刚开始做 CTF 题的时候，最反感“查看源码”这种题，觉得太没技术含量。后来被一道带有复杂前端逻辑的题目卡了很久，才意识到源码里藏着大量关键线索。写页面的人留下注释、变量名、调试信息是非常正常的事。学会从源码中提取信息，是代码审计和渗透测试的基本功，也是区分“会用工具”和“会做测试”的重要分界线。
ctfshow 的 web1 虽然简单，但如果你认真走一遍全流程，会发现它就像一个最小的闭环：给你一个目标，让你寻找线索，最终得到一个答案。这个闭环以后会反复出现。能把闭环中的每一步都做到不慌、不漏，你才算真正迈进了 Web 安全的大门。
