CTF新手向：从HDCTF Welcome题看Web信息收集与源码审计

最近在NSSCTF平台上刷WEB方向的题目，一道HDCTF 2023的Welcome To HDCTF 2023让我印象很深。名字带Welcome，难度确实是新手友好型，但它是那种“看一眼就会、不看就得折腾半天”的题。我以为直接出flag，结果还是走了几步流程才拿到。

这道题很适合刚接触CTF、还没建立Web解题思路的朋友拿来练手。它不涉及复杂的注入或绕过，核心考的就是信息收集和源码审计意识——这两个能力恰恰是后续打任何Web题的地基。这篇文章我就以这道题为主线，把整个解题过程、背后的原理，以及常见坑位都展开聊聊。

1. Welcome题到底考什么：签到题背后的出题逻辑

1.1 为什么CTF比赛都要放签到题

大型CTF赛事通常都会设置一道Welcome题，位置一般放在WEB方向第一个，分值不高，难度也低。出题人的目的很清楚：让参赛者先热身，确认账号能正常登录、题目环境能正常打开、提交flag的流程是通的。比赛开始后的前半小时往往是平台最拥挤的时候，如果签到题都做成需要绕半天弯子的难题，参赛者还没开始打正题就被卡住，体验会很差。

但签到题不等于“白给”。很多出题人会在签到题里埋一点小机关，让新人在找flag的过程中顺带学会看源码、看响应头、看JS文件——这些恰恰是Web安全的基础操作。我见过太多新手一上来就问“flag在哪”，其实答案就摆在浏览器里，只是不知道怎么找。

所以HDCTF的这道Welcome题也不例外，它的定位就是“让你能拿到flag，但至少要动一下手”。别小看这一下，整个Web渗透的起点就是从“多看一眼”开始的。

1.2 Welcome题的常见形态与破题突破口

这几年我刷过不少赛事的Welcome题，发现它们的出题套路高度集中在几个模式上，摸清这些规律，基本就等于拿到了一半的答案。最常见的无非四种。

第一种是注释藏码。flag直接写在HTML注释里，F12打开就能看到。这是最原始也最常见的签到形式，出题人想教的就一件事：网页源码不是秘密。

第二种是响应头藏码。flag拆开塞进HTTP响应头字段里，比如自定义的X-Flag头，或者藏在Set-Cookie、Server字段后面。这类题要求你会用浏览器的开发者工具切到Network面板，会看请求和响应。

第三种是JS逻辑藏码。flag可能藏在某个JS变量里，或者需要你在控制台执行一段代码才能触发出来。有些出题人喜欢把flag拆成几段，一段在HTML里，一段在JS文件里，拼起来才是完整内容。这已经开始考验耐心了。

第四种是基础编码混淆。拿到表面字符串后还需要URL解码、Base64解码，或者十六进制转ASCII，折腾一步才能看到真正的flag。

Welcome To HDCTF 2023这道题我印象中走的还是“源码追踪+信息拼凑”的老路，但里面加了一个我一开始没想到的环节——直接搜页面文本搜不到，得切换思路再看开发者工具的更多细节。这种设计在比赛环境里很常见，因为靶机环境本身会有面板信息、题目描述等附加区域，flag不一定只出现在一个地方。

提示：遇到Welcome题别急着到处乱点，先把浏览器开发者工具打开，按顺序看Elements、Network、Console三个面板，大部分签到题就在这三板斧之内。

2. 工具准备与开题前的基础检查

2.1 浏览器和开发者工具是主战场

做Web题不需要装什么重型工具，一个经过调教的浏览器就够应付绝大多数签到题。我推荐用Chrome或者Edge，原因很简单：开发者工具直观、Network面板信息完整、对新手友好。

进入题目环境之前，我习惯先把开发者工具的设置过一遍。一个容易被忽略但影响效率的选项是“Disable cache（禁用缓存）”。勾选之后，每次刷新页面都会重新加载所有资源文件，不会因为浏览器缓存导致你看到旧的HTML或旧的JS。很多新手开了F12，改了几次代码之后再刷新，发现页面没变化，还以为自己操作错了，其实是被缓存坑了。

另一个建议是打开“Network”面板后勾选“Preserve log”，这样页面跳转时历史请求不会清空，能看到完整的请求链路。有些题目的flag藏在某个跳转响应里，如果没开这个选项，跳到下一个页面后前面的响应就丢了，Z这点细节能帮你少走很多弯路。

2.2 开题后的第一件事：确认题目环境与信息

很多人拿到题目URL，第一反应是直接打开页面找flag。这个习惯不能说错，但少了关键一步——先读题。

CTF平台的题目卡片上通常会有题目描述、难度标签、作者备注等信息。有些出题人会把提示直接写在描述里，比如“flag在响应头”“看看管理员有没有留下什么”。我见过不少参赛者，题目描述写着“Do you know robots.txt？”，结果还在源码里翻半天。先花三十秒把题目信息读完，这件事的成本最低，收益却最高。

确认题目环境正常也是开题后必须做的一步。点开题目后看到的是空白的404、数据库报错，或者干脆连接不上，都要记录下来。环境问题在CTF比赛中非常常见，很多题目开出来之后靶机还没完全启动，或者容器因为长时间没人访问被回收了。这时候一头扎进去找flag是没有意义的，代码逻辑没问题也找不到，因为服务根本没起来。

我个人的固定操作顺序是：先读题，再访问URL确认页面正常加载，然后顺手右键查看页面源代码，最后按F12切到Elements面板开始系统排查。这套流程走下来，Welcome题基本没有跑得掉的。

3. 完整解题流程实录

3.1 第一步：全局查看源码，先从HTML注释开始

拿到Welcome To HDCTF 2023这道题的容器地址后，我打开页面，发现是个很简单的内容页，看起来就是一个欢迎界面，没有输入框，没有跳转按钮，干净得像一张白纸。

面对这种页面，新手的第一反应通常是“完了，怎么什么都没有”。其实恰恰相反——页面越空，说明线索越藏得深，出题人已经把flag放在某个隐蔽角落等你去发现。我直接在页面上右键选择“检查”，或者按F12进入开发者工具，然后盯着Elements面板里的HTML结构逐行看。

HTML注释是第一个排查点，也是Welcome题命中率最高的位置。我往下滚动HTML，看到有一行注释写着类似“ ”的内容。前半段flag到手。这里很多人会以为只有这一段，其实出题人更鸡贼的地方在于，flag从来不是一次给全的。

拿到第一段后不要停，继续把整个HTML结构看完。有时候出题人会把信息藏在标签属性的value值、data-*属性、甚至某个看似无意义的class名称里。手工看源码很容易遗漏，我习惯用浏览器的搜索功能，在Elements面板里直接Ctrl+F搜索“flag”这个关键词，能快速定位所有包含flag字样的位置。这个操作在代码量较大的题目里特别管用。

3.2 第二步：检查外部资源与响应头，寻找剩余拼图

第一段flag到手后，我按惯例切到Network面板，重新加载页面。这一步把页面加载过程中产生的所有HTTP请求都记录下来，包括HTML文档本身、JS文件、CSS文件、图片、字体等。逐个点开看请求的响应内容。很多新手的习惯是只盯Elements面板，忽略Network面板，这会导致大量线索被漏掉。

我注意到其中一个外部JS文件有点可疑，文件名看起来不像常规框架生成的随机文件，像出题人手写的脚本。点开这个JS文件查看响应体，果然在里面发现了一段变量赋值。变量名取得很随意，看起来就是顺手写的，但值是一串疑似编码的文本。把这段组合到刚才的HTML注释内容里，确认了格式，flag的中间部分也浮出水面。

接下来还要看响应头。切换到Network面板，选中文档请求那一条，查看Response Headers。有些出题人喜欢在响应头里塞额外的flag分片或提示信息，常见的是自定义头如X-Flag、Flag-Part，或者塞进 Server、Set-Cookie 这种常规字段里。这道题让我感觉得出来，出题人把最后一个片段放在了一个不太容易注意到的地方，需要你在响应细节里多停留一会儿。

注意：响应头里的字段并不区分大小写，你看到的是 x-flag 还是 X-Flag 都一样。另外，如果使用的是浏览器的“检查”功能，响应头在Headers标签页里，源码里看不到这一段，必须通过这个入口看。

3.3 第三步：拼接flag并检查格式

三段内容凑齐后，需要把flag完整拼出来。正确的CTF flag格式通常是固定前缀加内容，比如题目明确要求的前缀加一大串可读文本。拼接好后不要急着提交，先确认几个细节。

第一，确认拼接顺序。HTML注释里的part1、JS里的part2、响应头里的part3，出题人既然标了part，就按顺序组合。第二，确认提交格式。有些平台要求格式统一写在题目描述里，比如“flag格式：flag{xxx}”，有些则需要你从题目简介里自己找线索。第三，确认是否有多余字符。有些出题人会故意在分片前后塞空格、换行符或者看起来像装饰性的符号，拼接前把两端清理干净。

提交到NSSCTF平台的flag验证框，返回正确提示，这题就过了。

4. 实战中的常见问题与排查清单

4.1 环境类问题

刷题过程中最影响心态的不是题目不会做，而是环境的恶意。第一次打开题目页面，等了很久一直是白屏。排除了浏览器缓存的因素后，我刷新了几次，最后切到Network面板看到请求一直处于pending状态，判断是容器还没就绪。又等了两分钟左右再刷新，页面正常加载了。

这类问题在比赛高峰期特别常见。NSSCTF这类平台通常用动态容器，点击开题后系统才临时分配环境，有时候容器拉起需要时间。如果你刷新三次以上页面还是白屏，可以尝试先关闭题目页面，回到题目列表重新开启。但要注意，有些平台重新开题会分配新地址，原先访问的旧地址会失效。

还有一种情况是题目容器因为空闲超时被回收了。开着题目页面好长时间不操作，再回来刷新就连接不上。这不是题目问题，重新开启即可。

4.2 思路类问题

如果三位一体的排查都做完了，还是没找到任何线索，需要考虑是不是遗漏了某些区域或者某些信息形式。我整理了一份排查顺序，按优先级排列：

如果以上全部排查完还是空白，那说明题目很可能不是纯静态信息类，需要交互操作或特定路径才能触达flag，比如点击某个按钮触发JS函数、向特定接口发送请求、或者访问一个隐藏路径。这时候就要升级思路，开始看JS文件里的函数逻辑，看它怎么处理用户输入、往哪个地址发送请求。Welcome题的变体再多，本质也就是这几类。

5. 从签到题延伸开的学习建议

5.1 这道题背后真正要练的能力

很多人刷完Welcome题就急着往难题冲，我觉得这是错误的节奏。签到题表面上是送分，但它认认真真覆盖了两个Web安全的基础功：信息收集与前端代码审计。

信息收集不是指用扫描器去扫路径、扫目录，而是“关注细节”的敏感度。一个合格的解题者，看到页面第一眼，脑子里应该自动弹出几个问题：源码看了吗？外部资源看了吗？响应头看了吗？请求链路完整吗？这些问题的答案直接决定你的解题节奏。Welcome To HDCTF 2023这道题，本质上就是逼你形成这个反射动作。

前端代码审计则是更进阶一点的能力，指的是通过阅读HTML、JS、CSS来理解应用逻辑，找出隐藏入口或安全缺陷。很多Web题，尤其是前端类的，用到的技术就是这道Welcome题的IFrame、变量、事件绑定这些概念。把Element、Network、Console、Sources这几个面板摸熟，你做后续题的底子就打好了。

5.2 后续可以刷的同类题型

如果你已经能不看攻略独立完成这道题，下一步可以找几个方向关键词去扩大题库：源码泄露类、响应头利用类、JS分析类、基础编码类。这些题型在NSSCTF的WEB入门区都有覆盖。

我的建议是别急着啃难题，先把同类型的签到题刷到“闭着眼都能走完流程”的程度，形成肌肉记忆。然后逐步往上加难度，比如加上简单的参数污染、弱会话逻辑、或者伪协议利用。学习安全没有捷径，但有一条比较踏实的路线：把每一道简单题背后的能力点抠出来，练到条件反射。

5.3 我踩过的一些坑，写在这里供参考

这次刷题过程中，我最深的体会是排序问题。有一阵子我的习惯是看到JS文件就先去追逻辑，反而忽略了HTML注释里现成的flag。后来调整了顺序：先看HTML、再看响应头、最后深入JS逻辑。这套顺序能覆盖绝大多数出题人的思路，因为出题人设计flag位置时，也是按可见度从高到低排列的。

另一个坑是环境问题倒腾了我不少时间，有一段时间我反复确认代码细节，翻来覆去也没找到问题，后来才发现是容器没起来。这是在刷题平台上的常规体验，别把技能问题误判成自己的问题，也别把环境问题误判成题目问题。判断依据很简单：如果页面加载本身就不正常，那就别找flag了，先处理访问问题。

最后再说一个小技巧：拼flag的时候，如果发现提交格式总是不对，检查一下拼接顺序与是否有隐藏字符。把拼好的内容粘贴到一个纯文本编辑器里，用肉眼核对一遍。有时候问题出在复制时多带了一个不可见字符，这种低级错误最容易让人血压升高。