CTFSHOW WEB入门 爆破 web21从一道登录题看爆破的完整套路拿到 CTFSHOW WEB入门 爆破 web21 这道题的时候多数人和我一样第一反应是这不就是个登录页爆破吗直接上字典跑就完事了。但真正上手之后你会发现如果只会上工具点开始爆破这一题很可能跑半小时都毫无结果。web21 的巧妙之处在于它考的并不是密码猜得对不对而是你能不能看懂请求包里被编码过的认证参数。这篇文章我就从实际做题的角度把 web21 的完整解题链路、Burp Suite Intruder 的正确用法、以及题目背后能迁移到真实防御体系的知识点全部拆开讲一遍。无论你是刚接触 CTF 的 Web 方向新手还是已经被爆破题卡过几次但没真正理解的选手这篇都能帮你把爆破这件事彻底打通。1. 开题web21 到底在考什么1.1 题目现象与最初的抓包观察打开靶场环境映入眼帘的是一个很朴素的登录表单有用户名输入框和密码输入框没有任何验证码没有注册入口也没有找回密码之类的功能。随手输入admin / 123456提交页面提示登录失败。这时候如果只盯着页面看题目就卡死了因为没有更多信息。正确的下一步是打开 Burp Suite 抓包。我习惯在浏览器里配好代理然后重新提交一次登录请求在 HTTP History 里找到刚才的 POST 请求。仔细看请求内容时一个细节立刻引起了我的注意请求参数里并没有出现明文形式的username和password字段取而代之的是一段看起来很像 Base64 编码的字符串。把它复制出来解码内容是admin:123456正好是刚才输入的用户名加冒号加密码的组合。这个发现基本确定了 web21 的考点方向登录认证信息被做了编码处理题目希望做题者能够发现这个规律然后在爆破时对字典中的每个密码做同样的编码变换再发送给服务器进行尝试。1.2 识别爆破点的三个信号很多刚入门的朋友分不清一道题到底适不适合爆破这里我总结三个在 CTF 靶场里非常常见的信号只要同时出现基本可以判定这是一道爆破题。第一个信号是登录接口存在明显的脆弱的认证设计比如无验证码、无失败次数限制、无登录锁定策略。靶场环境为了保留解题路径往往不会做真实业务系统里那些防护措施。第二个信号是请求包中存在可预测的编码参数像 Base64、URL 编码、十六进制、甚至简单异或当你能从请求包里解码出自己输入的明文时说明服务器对输入只做了编码变换并没有真正加密这就为你构造爆破 payload 提供了明确的变换规则。第三个信号是响应结果存在可区分性比如登录失败返回固定文案和固定长度登录成功返回 flag 或者跳转到新页面这种明显的差异让爆破工具能够通过响应长度或关键字来判断是否成功。对照这三个信号web21 三条全部命中。所以这道题不是你猜不猜得到密码的问题而是你能不能把爆破和编码处理这两个技能在同一个请求里正确组合起来。1.3 这道题的实际考点拆解表面看 web21 是在考弱口令爆破但实际考点可以拆成三层。第一层是信息收集能力你得会抓包、会看请求参数、会识别 Base64 特征这决定了你能不能发现编码规律。第二层是工具使用能力你得会配置 Intruder 的 payload 处理规则把字典里每个密码都动态拼接并编码成目标格式这决定了爆破能不能跑对地方。第三层是结果验证能力你得会通过响应长度差异定位成功请求而不是盲目翻几百条记录。这三层能力在后面的 CTF 题目里会反复用到尤其是对 payload 做预处理这个思路几乎能迁移到所有带编码逻辑的爆破场景。web21 作为入门题的价值就在这里它用最简单的形式逼你把这条链路完整走一遍。2. 爆破不是乱试Burp Suite Intruder 的正确打开方式2.1 为什么选 Intruder 而不是自己写脚本讨论爆破工具时总有人说这点东西写个 Python 脚本不就行了。对于 web21 这种单点登录爆破写脚本当然能解但我不建议入门阶段一上来就写脚本原因有三个。第一Intruder 的 payload 处理功能是图形化、实时可见的你加一条先加前缀再 Base64 编码的规则马上就能在 payload 预览里看到变换后的实际效果这比写代码调试要直观得多。第二Intruder 内置了响应长度标记、状态码标记、关键字匹配等结果筛选功能跑完几百条请求后一眼就能从结果列表里找出异常项。第三Burp Suite 本身就是做 Web 渗透测试的标配工具你早晚要熟练使用它与其先在 Python 脚本上磕磕绊绊不如趁 web21 这道题把 Intruder 的操作彻底练熟。当然脚本爆破在某些场景下确实有优势比如需要自定义复杂编码逻辑、需要并发控制、需要对接自己的字典库。但那是熟练之后的事入门阶段最重要的是把可视化的流程吃透。2.2 四种 Attack Type 怎么选web21 该用哪种Intruder 提供了四种攻击类型很多人一上来就懵不知道点哪个。这里我用一个表格把这四种类型讲清楚攻击类型适用场景载荷位置特征Sniper狙击手只有一个可变位置比如只爆破密码同时只能标记 1 个 payload 位置Battering Ram破城锤多个位置共享同一份 payload所有标记位置同时填入同一个值Pitchfork草叉多个位置使用不同的字典一一对应字典必须等长按行对应组合Cluster bomb集束炸弹多个位置分别遍历所有字典组合笛卡尔积会产生爆炸级请求数量回到 web21前面我们已知用户名字段是固定的比如admin需要变化的只有密码部分而最终请求里是用户名:密码整体做 Base64。这时候最合适的方案是 Sniper 模式只标记密码这一个开始位置然后在 payload 处理规则里给它加上admin:前缀再做 Base64 编码。实际做题时我见过不少人用 Cluster bomb 把用户名和密码都标记成变量跑出来一个巨大的笛卡尔积集合。对于 web21 来说这是浪费因为用户名只有一个候选值Pitchfork 和 Cluster bomb 在这种单变量场景下没有意义。Sniper 模式配合 payload 处理规则才是这道题最优雅的解法。2.3 字典怎么选才不浪费时间爆破的成功率很大程度上取决于字典选择。web21 这类入门题的密码通常不是随机字符串而是有一定规律可循的弱口令。我个人的习惯是优先尝试常见弱口令 Top100比如123456、admin888、password、admin123、123123这些然后再根据题目背景信息适当扩展。Burp Suite 自带的字典列表里有一个/usr/share/wordlists路径下的常见字典还有 SecLists 这类开源字典集但局部的入门题目不需要上大招。先用小字典快速跑一遍命中就省时间没命中再换大字典。这里有一个判断命中与否的关键技巧正常爆破几百条请求后你会在结果列表里发现某一条响应长度和其他几条明显不同这就是你要找的候选对象把它点开看响应内容就能确认是否成功。响应长度突变的原理很简单登录成功页面会包含 flag 或跳转逻辑页面体积必然和登录失败页有差异而 Intruder 默认就会按响应长度排序异常项往往自动排在最前面。3. web21 完整解题过程从请求包到 flag3.1 第一步让 Burp 接管浏览器流量无论你用的是哪个版本的 Burp Suite第一步都是确认代理监听正常。我习惯使用默认的127.0.0.1:8080浏览器端通过 SwitchyOmega 或 FoxyProxy 这类代理插件把流量导向 Burp。如果你用的是 Firefox可以直接在浏览器设置里把 HTTP 代理和 SSL 代理都填上127.0.0.1和8080Chrome 用户没有内置代理配置界面推荐装一个代理切换插件。配置完成后先访问一个普通网站或靶场页面确认 Burp 的 HTTP History 里能刷出请求说明流量接管成功。这一步看似基础但很多人栽在这里。尤其是当你同时开着系统代理和插件代理时会出现请求时通时不通的诡异现象。我的建议是只用一种方式配置代理并且每次测试前先看 HTTP History 是否刷新确保链路通畅再动手。3.2 第二步定位编码逻辑并构造 payload代理配置好之后回到靶场登录页输入admin / 123456提交然后回到 Burp 的 HTTP History找到这条 POST 请求。右键把它发送到 IntruderSend to Intruder快捷键 CtrlI。接下来是核心操作环节。在 Intruder 的 Positions 选项卡里设置攻击类型为 Sniper。把请求包中密码对应的位置标记为 payload 位置也就是说把那段编码字符串中对应密码的部分替换成§标记。如果你看到的请求体里是一整个 Base64 字符串比如YWRtaW46MTIzNDU2那么你真正要标记的是密码对应的那一段。但为了让 payload 处理规则更清晰我通常直接标记整个编码字符串然后在规则里重新生成它这样不容易出错。具体做法选中整个 Base64 字符串点击Add §然后清空它的值为空或者保留一个占位符。然后在 Payload Processing 里点击 Add添加两条规则第一条是 Add prefix前缀填admin:第二条是 Encode编码方式选 Base64-encode。这样 Intruder 在发送请求时会先把你字典里的密码值拼上admin:前缀再对整个字符串做 Base64 编码最终填入请求包的位置。这里要特别注意规则的执行顺序Intruder 的 payload 处理规则是自上而下依次执行的。先加前缀再做 Base64 编码结果才符合admin:密码的整体编码规律。如果顺序倒了先编码再加前缀请求值就完全不对了爆破自然全部失败。3.3 第三步设置匹配规则跑出 flag在 Intruder 的 Options 选项卡里可以设置一些请求和响应相关的选项比如是否跟随重定向、超时时间等。对于 web21 这种场景默认设置基本够用唯一建议调整的是如果网络不太稳定可以把超时时间从默认值稍微调大一些减少因为网络原因导致的误判。然后回到 Payloads 选项卡。Payload type 选 Simple list然后在 Payload Options 里点击 Load 加载你的密码字典。如果没有现成字典也可以手工输入几个常见弱口令但效率太低建议还是准备一份 Top1000 的常见密码字典。一切就绪后点击右上角的 Start AttackIntruder 会弹出新的窗口开始发送请求。跑完后点击结果列表上方的 Length 列进行排序你会发现大多数响应长度集中在一个固定值左右而某一条或几条响应的长度明显不同。点开那条异常请求在 Response 里搜索flag关键字或者在页面内容里直接看就能找到这道题的 flag 了。拿到该题 flag 后整个解题闭环就完成了。整个过程的核心不是密码本身而是你通过 payload 处理规则让每次请求都符合服务器预期的编码格式再加上一个有效的弱口令命中两者缺一不可。4. 从攻击视角转到防御视角web21 背后的防护设计课4.1 暴力破解为什么至今仍然有效很多人干了这么多年开发觉得暴力破解是上古时代的技术现在系统都有验证码和锁定机制应该早就失效了。但现实是暴力破解在 Web 安全领域依然高居漏洞榜单前列根本原因在于人这个环节始终是最薄弱的。弱口令的存量超乎想象。哪怕是 2024 年依然有大量系统在用admin / 123456、root / root、test / test这种组合。很多内部系统的运维账号、测试账号、默认账号从未被修改过。密码策略形同虚设有些系统只要求长度不要求复杂度用户就填一个aaaaaaaa完事。再加上多个系统共用同一套密码的习惯广泛存在一个地方泄露其他系统都可以用撞库方式尝试登录。web21 这种靶场题目设计的登录接口没有验证码、没有锁定、没有延迟本质上就是模拟了现实中那些防护薄弱、仅靠密码不可枚举来硬扛的系统。当密码空间不够大的时候枚举就是高效的攻击方案这是数学层面的事和工具无关。4.2 常见的防爆破手段与绕过思路既然爆破仍然有效防御方就必须理解攻击方的绕过思路。我把常见的防爆破手段和对应的绕过思路整理在下面方便对照理解。防御手段原理攻击方的绕过思路验证码增加人机识别门槛OCR 识别、验证码复用、绕过前端校验直接发请求登录失败锁定连续失败后锁定账号或 IP分布式代理池换 IP、慢速爆破、直接对无锁定接口下手请求频率限制限制单位时间内的请求数把爆破速度降到限制以下用长时间慢跑绕过增值信息校验如手机验证码、邮箱验证码前提是能获取验证码否则这条路就封死了双因素认证密码之外再加一道凭证针对性地转移攻击目标到会话管理或业务逻辑漏洞这里的核心认知是爆破攻击不总是在线对登录口海量试密码攻击者往往先侦察找出没有防护的入口比如子系统的测试接口、旧版本接口、API 网关未接入统一认证的旁路接口。防护体系必须覆盖所有入口而攻击者只需要找到一个突破口。这也是安全领域常说的一句话防御者要防住所有路径攻击者只要突破一条路径。4.3 作为开发者应该怎么做刷完 CTF 题目最大的收获不只是会解题而是理解这类题目在真实系统中的映射这样你以后写代码时才知道哪些坑不能踩。作为一名写过不少业务系统的开发者我的经验是防爆破的最佳实践可以用四个词概括延迟、锁定、验证、监控。服务端做登录校验时务必加固定延迟或随机延迟哪怕是 200 毫秒都会让爆破速率指数级下降加上失败次数锁定或临时封禁能够直接中断攻击者的连续性验证码可以放在风险触发后而不是每次登录都弹兼顾体验和安全最后把登录失败率、异地登录、异常时段登录等指标接入监控告警第一时间发现爆破苗头。回到 web21 这道题它最值得反思的一点是把认证信息用 Base64 编码根本不算加密这只是编码是任何人用肉眼就能识别的格式。有些开发者以为把admin:123456转成 Base64 就安全了这等于把钥匙藏在门垫下面稍微有点经验的人一伸手就摸到了。真正的安全要靠服务端校验逻辑、密钥管理和证书体系而不是前端数据表现层的混淆。5. 实操踩坑记录编码、线程与字典的三大坑5.1 payload 编码没生效的典型症状我在跑 web21 的时候第一次犯的错就是 payload 处理规则的顺序反了导致跑出来的请求长度全部一致响应内容也全部是登录失败。这种情况很典型如果 Intruder 结果列表里响应长度几乎完全相同且没有任何一条出现异常长度多半是 payload 格式不对。排查方式是回到 Intruder 的 Payloads 选项卡看 Payload Processing 规则列表再点一下预览按钮查看生成出来的实际 payload 样本。正常的 payload 应该是一段以YWRtaW46开头的 Base64 字符串其中YWRtaW46就是admin:的 Base64 编码。如果你预览出来的是MTIzNDU2YWRtaW46这种密码在前、前缀在后的形式说明规则顺序错了把 Encode 挪到 Add prefix 之后即可。另一个常见的症状是全部请求都是 404 或 500 状态码这可能是因为你把请求包里的其他参数也误标记成了 payload 位置导致服务器无法识别请求格式。解决方法是回到 Positions 选项卡确认只有目标位置存在§标记其他参数保持原样。5.2 线程配置的激进与保守Intruder 的 Threads 选项默认是 1也就是串行请求。对于 web21 这种本地靶场串行速度比较慢尤其是字典有几千条时等起来太煎熬。很多人为了提高速度直接把线程拉到 50、100但这会带来两个问题。第一个问题是靶场后端可能扛不住高并发表现为大量请求超时或者连接被重置反而降低爆破效率。第二个问题是本地网络和 Burp 自身的处理能力有限线程开太高时 Intruder 窗口会明显卡顿结果列表刷新变慢反而影响观察。我个人的经验是先从 5 到 10 开始尝试观察响应时间和稳定性再逐步往上调。这类入门题通常跑几百条字典就出结果了线程 10 足够没必要为它把整台电脑的资源都占满。5.3 字典命中的边界情况还有一个容易忽略的细节是密码的边界情况比如空密码、密码为用户名本身、密码与用户名相同但大小写不同。有些题目为了降低难度会把密码设置成admin本身或admin888这类组合往往在你的 Top10 字典里就有。另外有些题目的用户名可能不是admin而是ctfshow、test、user之类这就需要你在初步没有结果时回头考虑用户名是否也需要枚举。判断是否需要把用户名也加入爆破范围的标准很简单先看请求包里能不能看出服务端提示的用户名错误和密码错误是否分开返回。如果服务端不区分用户不存在和密码错误那你先爆破用户名再爆破密码就是两段独立的事情如果服务端统一返回登录失败你也可以用 Pitchfork 或 Cluster bomb 把用户名和密码一起枚举只是请求量会大很多合理规划字典才能避免跑太久。做完 web21 之后再回看会发现这道题真正消耗时间的地方不是爆破本身而是你是否能快速识别编码规律并正确设置 payload 处理规则。这种先观察请求、再定制工具的做题习惯比会背几个漏洞类型重要得多。我在实际刷题过程中的体会是每做完一道题就把请求包、编码逻辑和最终 payload 规则存成自己的笔记下次遇到类似题目直接套模板效率能提升很多。最后再分享一个小技巧别小看响应长度排序这个功能爆破题里九成的 flag 都藏在长度异常的那条响应里。