CTF里Web题永远是参赛人数最多、套路也最杂的一个方向。很多新手拿到一道Web题上来就急着到处点按钮、翻参数结果折腾半天连Flag的影子都没见到。其实Web题的Flag就藏在两个维度里一个是信息收集的广度一个是请求构造的深度。只要把这两条线捋清楚大部分题目都能在半小时内解决。这篇Writeup我打算把平时打CTF Web题最常用的几招拆开来讲配合实战中容易踩坑的地方让刚入门的朋友少走点弯路。题外话一句下面提到的所有技巧只适用于CTF竞赛环境或者自己搭的靶场千万别拿去对着公网系统乱试。这是底线。1. 第一层侦查藏在页面代码与资源文件里的Flag1.1 先从HTML源码和注释信息查起很多新手拿到题第一反应是看页面效果实际上Web题80%的线索都藏在源码里。我见过太多人忽略一个最简单的事实出题人就怕你找不到Flag所以往往会用最直白的方式提示你——注释。某次模拟项目X的题打开页面只有一行字“Welcome to the challenge”底部有一张图片。我习惯性地按CtrlU看源码翻到中间看到一段!-- flag_part_1: ctf{...的注释然后又发现页脚隐藏着一个div idadmin styledisplay:none里面放着一个后台入口。这就是个典型的信息收集题Flag分成两段一段在注释里另一段在后台里而你唯一要做的是看代码。源码里常见的信息泄漏点包括HTML注释直接写Flag、提示下一个入口、透露后台账号格式。隐藏表单域比如input typehidden namerole valueuser这种就是典型的越权入口。JS文件里的接口地址很多出题人会在JS中写/api/getFlag之类的接口名但不告诉你参数。CSS背景图极少数题会把Flag编码成图片名字或者background-url的base64参数。看源码的时候别只盯着当前打开的这一个HTML右键查看外部引用的CSS和JS文件逐个点开看所有前端代码都算页面的一部分。另外火狐和Chrome的开发者工具里按CtrlShiftF可以直接在所有已加载文件中搜索关键词全局搜一下flag、ctf{、admin、api一分钟不到就能找出绝大多数页面级别的线索。1.2 robots.txt与备份文件的敏感信息泄漏如果源码里干干净净下一个要检查的就是站点根目录下面的标准文件。robots.txt在很多CTF题目里就是一个故意留下的提示板里面有时代码是Disallow: /admin.php有时候是一段需要解码的字符串。除了robots.txt我建议养成一个条件反射式的习惯访问页面的时候顺手探测这些路径.git/目录一旦存在整个源码都能用git命令还原出来。实操时可以先git clone整个站再git log查看提交记录Flag经常藏在某个历史版本里面。/.svn/、/.hg/目录.bak、.swp、.sav、~后缀文件比如index.php.bak、flag.php.swp。看到这类文件直接下载打开就是源码或者Flag。www.zip、web.zip、site.zip之类的压缩包出题人打包源码的时候忘了清理是很常见的事。phpinfo.php、test.php、info.php有人会问怎么知道该探测哪些路径呢推荐两个办法。一是用开源目录扫描工具扫一下CTF环境下网站路径不多几秒钟就出结果二是根据题目给的提示猜测如果题面写着“备份文件泄露”或者“源码泄露”那大概率就在上面这几个路径里。记住一个判断准则不管用什么工具扫出来的路径不是重点重点是你必须逐个访问并分析内容有些人扫出一堆目录但没耐心打开等于白扫。1.3 响应头与隐藏的服务端信息第三处容易被忽略的信息源是HTTP响应头。服务端返回的每个字段都可能被出题人做了手脚特别是Server、X-Powered-By、Set-Cookie这些。实战里我遇到过几种情况响应头里直接带着一段base64解码后是提示或者下一跳路径。Server字段写的是非标准值比如nginx/1.14.2 (php flag)这等于明着告诉你后面要用PHP的思路做题。自定义响应头X-Hint: /backup/指向源码备份路径。Set-Cookie里admin0把它改成admin1再刷新页面后台权限就出来了。看响应头这个习惯要养成到肌肉记忆里。打开开发者工具切到Network面板刷新页面挨个点击请求看响应信息也看请求信息。我见过有人Find Flag的时候反复刷新页面死活找不到其实线索就在加载图片的那个请求的响应头里。如果你用的是命令行方式调试curl -i、curl -v都可以直接看到完整头信息比浏览器里点来点去更快。2. 第二层探查请求交互中的参数重组2.1 URL参数与业务逻辑的绕过思路当页面本身和文件目录都探查完毕重点就转到请求参数上。Web题最经典的出法就是后台有个查询功能你传的参数不同返回的数据不同Flag只在特定条件下才会出现在响应中。这类题的核心是推断服务端代码逻辑。举个例子某个API是/api/user?id1返回普通用户信息试着把id改成2、3甚至0一旦某个ID返回了管理员信息这就是典型的IDOR越权。更进一步如果题目中传入的id是字母形式的用户名比如/api/user?nameadmin那就要注意有没有type、role这类辅助参数可以覆盖默认值。参数绕过的常见策略我整理成一张速查表情形尝试方式数字型参数改为0、1、-1或者字符串与数字混用布尔型参数true/false、1/0、yes/no数组型参数在参数后加[]如id[]1有时可绕过弱比较逻辑同名参数传多个id1id2不同中间件取值不同JSON体参数增加冗余字段或用数组覆盖原字段很多新手容易在这犯一个毛病看到参数就疯狂改但改完不观察响应变化。正确做法是每次改一个参数对比前后响应差异响应长度、状态码、页面标题都值得记录。比如某个题目传入pageabout正常返回传入pageadmin就302跳转到登录页那说明后端对名称有匹配关系接下来就该考虑路径穿越或者文件读取。2.2 Cookie与Session的伪造逻辑Cookie操作是另一个高频考点而且很多题出的特别直白。常见的类型有两种第一种是可见字段篡改。Cookie里直接放着userguest、roleuser、isAdminfalse把值改成admin和true再发请求Flag就到手了。这种题考验的不是技术是细心。第二种是签名类Cookie。有些题会给你一个形如sessioneyJ1c2VyIjoiYWRtaW4ifQ.x7y8z9的值前面那段像乱码的其实是base64编码的JSON。先用base64 -d解码看看内容能不能改再看后面那段签名算法。如果题目没给你密钥强行改内容大概率会失效但如果出题人用的是常见的弱密钥配合工具直接爆破出密钥再重新签一个并不难。还有个容易忽略的细节是Cookie的作用域。有些题Flag登录后能看见但登录用的是子域名下的Cookie主站读不到。这时候要检查Cookie的Path和Domain属性必要时手动在开发者工具里新建一个同名的Cookie到正确路径下再访问。这类问题很小但卡住很多人。2.3 HTTP请求方法重置与特殊方法Web题里还有一类考点考验的是对HTTP协议本身的理解同一个路径用不同的HTTP方法访问服务端处理逻辑会不一样。最常见的几个OPTIONS /查看服务器允许的请求方法响应里的Allow头直接告诉你哪些方法可用。PUT /shell.php服务器允许直接上传文件时用它传一句话木马。PATCH/TRACE/CONNECT部分服务框架会对这些方法做额外处理。某次做某跨平台系统题页面是一个静态文件服务器目录里有个flag.txt但直接访问GET /flag.txt返回403。我试了PUT /flag.txt上传内容成功覆盖了文件之后GET /flag.txt就把自己上传的内容返回了。整个题的本质就是考察HTTP方法配置错误。排查这类题目时我一般先把请求的Method列出来逐个访问相同URL观察状态码差异。一个方法一个方法地试虽然听起来笨但往往是一道题最核心的突破口。顺便提醒一句浏览器地址栏只能发GET请求要想发其他方法得靠Burp Suite、Postman或者curl-X参数。2.4 序列化数据与逻辑校验绕过稍微进阶一点的题会在传输数据里加入序列化字符串。典型的标识是形如O:4:User:1:{s:4:name;s:5:admin;}这样的PHP序列化格式或者直接用JSON格式包裹嵌套对象。碰到这类传输结构第一反应应该是后端有没有对这个反序列化结果做权限校验比如一个序列化对象里有is_admin字段默认是false把它改成true再重新编码发送回去很可能就绕过登录检查了。这里要特别注意格式一致性。PHP反序列化对字符串长度要求很严格s:5:admin里面的数字5必须和后面字符数完全一致多一个少一个都会报错或者导致变量不被解析。改的时候先数清楚字节数改完再用在线工具或者本地脚本重新生成一遍序列化串别手搓。3. 第三层突破Web漏洞利用的通用打法3.1 SQL注入的识别与绕过技巧信息收集和参数试探都做完还没拿到Flag那大概率要进入漏洞利用阶段了。Web漏洞的数量很多但CTF考得最稳定的还是SQL注入、文件包含、命令执行、文件上传这几类而且出题人通常会把过滤条件设置的比较简单真正难的是思路。SQL注入的识别过程其实很有规律。找到一个带参数的请求后先输入一个单引号看页面是否报错或者响应长度是否出现变化再尝试1 and 11和1 and 12对比返回内容差异。如果差异明显基本可以确定存在注入点。确认存在注入后一个比较稳的打法是用order by判断列数再用union select回显数据。CTF里有一类经典考察点列数知道但输出位置有限比如只显示第一条查询结果。这时候可以用union select里的冲空技巧让前面查询结果为空后面注入内容直接回显出来。过滤绕过是经常遇到的情况尤其是空格和关键字被替换。几种常用办法空格被过滤用/**/代替空格或者用%0a、%09这类URL编码字符。select被过滤尝试大小写混合SeLeCt或者嵌套写法selselectect如果后端只替换一次就有机会绕过。引号被过滤把字符串转成十六进制比如admin写作0x61646d696e。被过滤用like或者in替代。还有一种是盲注场景页面上看不到任何回显数据只能通过响应是否正常、响应时间长短来判断条件真假。手工试太慢的话直接用自动化工具跑布尔盲注和时间盲注。跑完拿到数据库名和表名再顺着去找Flag字段效率高很多。3.2 文件包含与命令执行的触发点文件包含类题目的特征非常明显URL里经常能看到?pageabout.php、?file./index、?templatedefault这类参数。它的本质是服务端把参数值拼到了文件路径里面导致你可以读取任意文件甚至执行PHP代码。CTF里最标准的一句话利用方式是PHP伪协议?pagephp://filter/readconvert.base64-encode/resourceindex.php用这种方式可以把PHP源码以base64形式读出来然后本地解码审代码找到下一段线索。还有一种方式是用data://伪协议直接写入PHP代码执行?pagedata://text/plain,?php system($_GET[cmd]);?这种技巧在一些过滤不严的题里可以直接getshell拿到flag之后别忘了清理日志和临时文件保持靶场干净。命令执行类的题则会在ping、转换工具、日志查看等功能里出现。判断方法是看参数值是否被拼进了系统命令字符串。比如有个参数ip127.0.0.1后端代码可能是ping $ip这时候输入127.0.0.1;ls就能看到目录列表。过滤绕过方面;、、|、反引号、$()可以多种方式组合被过滤了就用变量拼接、通配符、base64编码等方式拆解。3.3 文件上传与解析绕过场景文件上传题的核心是在扩展名和内容检查上做文章。出题人一般会校验后缀名和文件头但校验的规则往往不完整。几个常见的上传绕过策略改后缀为php5、phtml、pht如果服务器配置支持这些后缀解析就能执行。上传一个内容为图片文件头的PHP文件绕过文件内容检查。上传.htaccess文件把图片后缀解析成PHP。在文件名中加%00截断或者加上/.、/让后缀校验失效。用分号或者双扩展名混淆比如shell.php.jpg。上传成功之后访问路径是另一个坑。有些题上传目录不允许脚本执行但附件目录可以有些题上传后文件名被重命名下载时得去响应包或者目录列表里找真实文件名。实操时拿Burp抓完上传请求回显里通常会带上访问URL把那个URL复制下来直接访问避免自己瞎猜路径。3.4 弱口令与暴力猜解的正确姿势还有一种很多人嫌“智商低”但竞赛中很管用的题弱口令、爆破和猜解。这类题不考验技巧考验的是字典质量和耐心。常见账号密码组合就那几对admin/admin、admin/123456、admin/password有些题目还会在页面源码注释里留下管理员用户名那密码就可以用常见弱密码跑一遍。实际操作时可以用Burp的Intruder功能加载一个精简的字典把请求中账号和密码字段标出来设置好线程数几百个密码几秒钟就完成了。跑完的结果要看响应状态码、响应长度和跳转位置。如果某个密码的响应长度和别的不一样基本就是成功了。这里建议配置文件时别只盯着200状态码有些登录成功后用的是302跳转要跟着跳转过去确认。4. 实操中容易卡壳的点与排查速查表4.1 前端看似无输入点的情况很多新手在遇到一个只有静态页面的题时会想这题是不是坏了其实所有Web题都有一个入口只是入口可能藏在你预料不到的地方。完全没有输入框的题入口可能有几种存在形式某个按钮绑定了一个onclick事件触发了一个隐藏的fetch请求。页面的JS代码里有if(admin){ fetch(/getflag) }这类条件语句你需要手动在控制台执行相关函数。URL路径本身就是参数试着改路径的后半段。浏览器开发工具的Console里可能被写入了提示信息有些出题人会用心输出日志。遇到这种情况我个人的处理顺序是先看JS文件列表再在全局搜索中找fetch、ajax、XMLHttpRequest这些关键字顺藤摸瓜找到接口地址。接着把接口地址直接输入浏览器访问再看返回数据。很多题到这一步就解出来了。4.2 请求被重定向或者状态码异常有时候明明参数传对了页面却一直302跳转跳来跳去回到首页。这时候别急着换思路先看看跳转目标地址。如果跳转到login.php说明鉴权没过回头检查Cookie或者Session如果跳转到index.php?err1可能是参数格式不对。状态码也是一个很好的线索源状态码常见含义200正常返回看内容301/302重定向看Location头403权限不足尝试加头或改方法404路径不对检查大小写和后缀500服务端报错查看响应体错误信息有些题故意把正确页面做成403让你以为这条路走不通实际上加上一个特定的请求头X-Forwarded-For: 127.0.0.1或者Referer就能访问。开发代理或者WAF校验的场景在CTF里出现的概率不低多试几种头没坏处。4.3 编码与加解密的常见形态Flag和提示信息经常以编码形式出现最常见的几种是base64、十六进制、URL编码和md5。识别方法其实很简单base64的特征是大小写字母加数字加结尾十六进制是0x开头或者只有0-9a-fURL编码是大量的%号。解码的时候不要手算直接找在线工具或者本地命令echo ZmxhZ3t...} | base64 -d echo 666c6167... | xxd -r -p还有一种比较坑的点是二次编码比如先base64再URL编码解一层发现还带着%那就继续解第二层。有些题会故意把编码串放在Cookie、响应头或者图片链接的?src参数里专注于请求响应往返的数据总能看到。4.4 快速排查速查表平时打题我身边会放一张自己整理的排查表碰到卡壳就按顺序过一遍。也不怕大家笑话这个表虽然简单但真的帮我解过好几道卡了几个小时的题。排查项操作源码CtrlU看HTMLCtrlShiftF全局搜索flag关键字段目录探测.git、备份文件、常见目录名响应头检查每一个自定义头参数改数字、布尔值、类型、搞数组Cookie检查字段名和值的可篡改性请求方法尝试GET、POST、PUT、OPTIONS漏洞利用SQL注入、文件包含、命令执行、上传顺序上我始终建议先做前四项再做后三项因为前面几项成本低、速度快很多题目真的就是把Flag直接露在外面。5. 我在Web题上反复踩过的坑如果回头总结我把打CTF Web题最容易犯的三个错误列出来都是我看到身边朋友包括我自己常犯的。第一个是只看页面不看流量。尤其是刚入门的时候觉得开发者工具是给前端工程师用的其实CTF需求里数据包里的信息比页面渲染后的信息重要得多。以后遇到奇怪的现象第一反应先打开Network面板重新加载页面逐个请求检查。第二个是改参数不保留记录。很多新手在Burp里修改参数改乱了就忘了原始请求长什么样最后代码逻辑理不清楚。正确做法是先把原始请求保存下来每次修改都基于原始数据包改一条加一行注释理清哪里试过、哪里没试过。第三个是不肯主动扫描目录。很多人怕扫描工具动静太大实际在CTF靶场里完全没这个顾虑。快速扫一下公共目录拿到路径列表后再手动分析可以省下一大半试错时间。只要别忘了扫描结果必须人工验证就行。6. 最后分享一个实操小技巧也不算压箱底的东西就是我在一次一次试错里总结出来的当你确定思路正确但死活拿不到Flag的时候回去读一遍题面。CTF题目的描述出题人为了控诉难度或者给提示喜欢在题面里埋词。比如题面写着“藏在深处的秘密”“深处”可能就对应目录递归写着“管理员专属”那很可能就是越权或者Cookie伪造写着“只有本地能访问”那八成需要伪造来源IP。文本里出现的每一个词都值得想一想是不是技术暗示这个习惯帮我避开了很多弯路。另外解出题之后记得去看看这道题的官方Writeup或者别人写的Writeup对比自己的解法一般能学到一两个更巧妙的思路这也是CTF进步最快的方式。Web题这东西难度高低从来不在工具而在于你建模的思路信息收集做到什么程度参数分析得够不够细漏洞利用的判断准不准。多练几道题把这套流程变成肌肉记忆你也能做到看见页面就知道下一步该干什么。