卡住的时候：Web 渗透测试里最常见的六个死胡同

原创

Sink
Sink

船山信安

2026年10月1日 13:57
湖南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

实战笔记 · PENTEST

卡住的时候：Web 渗透测试里最常见的六个死胡同

渗透测试 · 写给打到一半打不动的那三小时

下午四点，Burp 的 HTTP history 里已经躺着四千条请求，没有一条能写成报告。不是刚进场那种\"从哪儿下手\"的茫然，是另一种——扫过了、点过了、试过了，目标还在那儿稳如磐石，连个像样的报错都不给你。这时候最耗人的不是技术，是判断力：继续挖，还是换方向。下面这六个死胡同，是 Web 渗透现场反复撞到的。它们不是六个技巧，是六个该止损的信号。

人在这种时刻做的往往是同一件事：把刚才那个动作换个参数再做一遍。字典换一套，编码加一层，目录字典再添两万条。看起来很忙，实际是在反复确认\"这里确实打不动\"。

我也这么干过。一整个下午对着一个登录框，Burp 挂着跑了两个小时，字典换了三套，密码全错，到头来一条都没写进报告。真正出东西的是同一个备案主体下的另一个子站——外包做的，框架还停在两年前，弱口令一撞就进。

认出死胡同，比多记十种变形手法有用。  这六个死胡同有个共同点：它们都不是\"技术不够\"，而是\"继续往下投入的边际收益已经归零\"。能认出这一点的人，和认不出的人，交付质量差得不是一点半点——前者把时间花在概率更高的地方，后者在原地把自己熬干。  这篇文章只做一件事：把\"该放弃\"的时刻标出来。

01打不动的往往不是技术点，是资产面

这类目标的典型长相很固定：主站挂在 CDN 后面，源站 IP 常规手段摸不到；Web 只开 80/443，后台藏在一个不告诉你路径的位置；登录框带验证码、带失败锁定；所有响应头都干净，连中间件版本号都不留。扫描器跑一轮，出来的全是\"信息\"级别条目。碰到这种目标，人的第一反应通常是\"再换个思路打一打\"，而我的建议恰恰相反：先确认它是不是真的值得打。判断依据是投入产出比，不是面子。你在主站上多待一小时，就少了一小时去翻那些没人管的历史资产——而后者出东西的概率，通常要高一个量级。

先看清楚它到底防在哪一层，别猜。拿 curl 看响应头是最省事的一步，五分钟就能分出\"是 WAF 在拦\"还是\"这个路径本来就不存在\"：

curl -I -m 5 https://target.example/

curl -s -D - -o /dev/null -m 5 https://target.example/

我的止损标准很粗暴：主站半小时到一小时没有任何\"可交互的异常反馈\"，就换资产。别舍不得，也别把\"我还没把所有变形都试完\"当成继续的理由——那句话我骗过自己很多次。

换资产不是瞎猜，有章法：

子域名。证书透明度日志、历史 DNS 解析记录、公开的收录与备案信息，都能捞出主站清单里没有的名字。名字越随意（test、dev、old、wx、api2）越值得看。

源站。CDN 挡着的，试试直连 IP 带上正确的 Host 头。有时绕过的不是防护，是\"没人想到那里需要防\"。

外包与第三方。甲方找供应商做的系统，常常不在同一条安全基线上。这是行业普遍现象，不是谁的失职。

移动端与前端产物。App 里写死的接口地址常常比 Web 老两代，老接口往往没有新接口那些校验；主站 JS 里的路径、注释、source map 是白送的路线图。

正门不好进，不代表这栋楼只有一个门。

02shell 拿得到，却出不去

命令执行到手那一刻，人最容易冲动。第一反应是反弹，试各种方式，全都静悄悄。然后开始怀疑是不是命令根本没执行成功，回头再确认一次——能执行，就是出不去。

卡住的根子在前面：进场前你没问过\"这个目标的网络边界长什么样\"。出网这件事由对方的防火墙、NAT、DNS 策略决定，跟你手里的技巧无关。技巧能决定你怎么用通道，决定不了通道存不存在。

顺序应该是先探测、后利用：

cat /etc/resolv.conf              # 看它用什么 DNS

env | grep -i proxy               # 看有没有代理线索

curl -s -o /dev/null -w \"%{http\_code}\" -m 5 https://example.com

getent hosts

三条路对应三种现实。直接出网最省事，能建 TCP 就什么都能谈。代理出网很常见，很多内网机器只允许走代理，线索就藏在环境变量和配置文件里。纯 DNS 出网这条常被忽略，53 端口往往是唯一放行的——用 dnslog 平台分配一个随机子域，让目标主机去解析它，平台侧收到查询记录，说明这条路通。这是判断思路，不是攻击动作。

三条都不通，也别沮丧。出不去恰恰说明你落在了一个隔离区里，而隔离区本身就是要写进报告的结论：这台机器被限制到什么程度、它还能访问哪些内网地址、同网段还活着谁。横向往往比出网更值钱——内网里那些默认不设口令、默认监听全网卡的服务，才是这次真正的目标。

出不去是边界在回答你，不是失败在回答你。

03过滤绕不过时，先判断它是不是真绕不过

绕过是门手艺，但它有个前提：对面用的是\"规则\"，不是\"架构\"。

看响应差异就能定性。被 WAF 拦通常有特征：一个不属于业务的拦截页面、一个固定得可疑的状态码、响应头里多出几个字段，或者带关键字与不带关键字时返回长度差得很规整。被应用自己转义则是另一副样子：业务页面正常返回，只是你的输入被原样显示出来，或者结果集永远为空。这两种都值得继续试。

定性这一步我只给自己十五分钟。十五分钟足够把响应头、状态码、返回长度排成一列对比；不够也没关系，不够本身就是一种答案——说明这个点的反馈信号太弱，不值得继续押注。

第三种完全不同：参数被强转成整型、查询走预编译绑定变量、或者取值来自白名单枚举。这种情况下你所有的变形都会被稳定吞掉，试一百次和试一次的结果一模一样。这是真死路，没有讨论余地。

判断依据只有一条：反馈变不变。能绕的过滤，你换一种写法，它的反应就不一样——有时候拦、有时候过、报错内容会变。这种有反馈的，值得继续投入。反过来，两小时里每种输入都得到同一个结果，那就不是你不够聪明，是它没有缝。

我给自己定的止损线是九十分钟。到点没进展，就在报告里降级成\"确认存在输入过滤，未能构造出完整利用链\"，然后换参数、换接口、换功能点。同一个授权范围里，通常不止一个参数在等着你。

顺带一句不受欢迎的话：把\"我试了两小时没绕过去\"写成\"不存在注入风险\"，是报告里最危险的写法。没绕过去和不存在，是两件事。

两小时没有反馈的过滤，通常不是难度问题，是方向问题。

04进了门，不等于能进后管

很多人在这里的心理是\"我都进来了，为什么进不去后台\"。这句话本身就说明模型建错了。认证只回答\"你是谁\"，后台回答的是\"你被允许做什么\"，中间隔着一整套授权体系。而这套体系通常是业务代码的产物，不是中间件的产物——所以它才有那么多缝隙。中间件给的拦截是统一的，业务自己写的校验是分散的，分散就意味着总有几个接口被漏掉。

我的做法是先把权限模型画出来，哪怕画在纸上。三问：系统里有哪几类角色？每类角色能看见哪些菜单和接口？数据是按什么维度切的——用户 ID、组织 ID、还是租户 ID？从上到下正好对应三种越权：低角色调高角色接口、同角色改别人的 ID、改组织标识看别家的数据。

怎么快速摸清？对比法。如果授权范围里提供了不同权限的测试账号，抓同一个操作在两种账号下的请求，差异全在接口路径和参数里。没有测试账号也没关系：前端路由表、没混淆的接口清单、报错信息里的字段名，都能告诉你系统里存在哪些角色、哪些资源。

还有个常见的坑：不少后台是前后端分离的，\"进不去后台\"只是前端没给你入口，接口其实挂在同一个网关上，鉴权在后端。这时候直接对接口发请求，比在登录框前耗着有用得多。前端藏了什么，后端不一定藏得住。

登录框是给人用的，接口才是给权限系统用的。你该测的是后者。

05危害写不出来，等于没找到

逻辑漏洞是最容易让人兴奋、也最容易写砸的一类。兴奋是因为\"别人没发现\"，写砸是因为它没法套用现成的评分模板。你写\"优惠券可重复使用\"，评审的人看到的是五个字，看不到后面的量级。

问题出在你把\"现象\"当成了\"漏洞\"。现象是\"这个请求返回了成功\"。漏洞是\"一个普通注册用户，不需要任何额外权限，可以在有限时间内重复领取，按当前客单价估算，单次滥用会造成可计量的资损\"。后面这半句才是报告。

我的自查清单只有三条：

谁能触发。需不需要登录？需不需要特定角色？需不需要拿到别人的会话？门槛越低越严重。

一次能拿到什么。是看到一条数据，还是拿到一笔钱、改掉一个配置？有没有放大手段——改数量、改金额、遍历 ID。

能不能规模化。能不能并发、能不能重放、有没有频率限制和风控。要手工点三十次才成功一次的问题，和脚本能跑一晚上的问题，不是一个等级。

这三条答不上来，只有两个选择：回去补利用链，把它变成能说清楚的东西；或者老实降级成\"风险提示\"，别硬凑高危。硬凑的后果是整份报告的可信度被拉低，下次你写真的高危，对方也会先打个问号。

还有个前提值得先检查：这个现象在真实业务流程里走得通吗？很多说不清危害的逻辑问题，其实本来就是业务允许的——比如那个接口本该只给内部系统调用，就不该出现在公网。这时候真正的漏洞是\"暴露面\"，不是\"逻辑\"。

说不清危害，通常不是表达问题，是利用链没闭合。

06时间过半，最该做的不是继续挖

这是六个里最难承认的一个。承认它，等于承认前面那几天有浪费。

但事实摆在那儿：第一天的资产梳理基于第一天的信息。那时候你不知道它的账号体系长什么样、不知道业务分几块、不知道哪些系统其实是一伙的。这些你现在都知道了。用今天的视角重看第一天那张端口表和目录结果，有些当时看不懂的条目，现在一眼就知道是什么。

具体做什么？不是重新扫一遍——那只是另一种形式的重复劳动。坐下来拿二十分钟列一张三列清单：已测且排除的、测过但只摸了表皮的、完全没碰的。中间那一列是重点。现场最容易出现的动作是\"打开一个功能，点两下，觉得没意思，关掉\"，而那一列里常常躺着这次最有价值的东西。

然后换视角。挖漏洞挖累了，换个不需要精巧构造的视角：去查那些\"配置错了\"而不是\"代码错了\"的问题：有没有未授权访问的服务、有没有能被公开拿到的备份或配置、有没有把密钥写进前端、第三方组件是不是停在很老的版本、共享文档里有没有躺着明文凭证。这类东西不需要多高的手艺，靠的是耐心和覆盖面。

还有一步很多人不肯做：去问。找熟悉业务的人聊十分钟——\"你这个系统里最麻烦的功能是哪个\"\"哪个流程是后来补上去的\"。后来补的流程，永远是校验最松的地方。这不是偷懒，这是信息收集的正当手段。

焦虑本身才是最大的成本。越焦虑，越倾向于做那些\"看起来在干活\"的重复动作。停下来梳理不是认输，是把剩下的时间挪到概率更高的地方。

卡住时的正确答案，常常是回头，不是硬闯。

ONE LINE
       卡住的时候，该换的不是手法，是维度。

参考来源

· OWASP Web Security Testing Guide（WSTG）：OWASP 官方维护的 Web 安全测试方法学，v4.2 版本于 2021 年发布，覆盖信息收集、认证与授权测试、注入类测试等条目

· MITRE ATT&CK：MITRE 自 2013 年起公开维护的对抗行为知识库，其企业版矩阵可用于描述测试过程中的战术与技术阶段

· NIST SP 800-115《Technical Guide to Information Security Testing and Assessment》（2008）：美国国家标准与技术研究院发布的信息安全测试与评估技术指南

· PTES（Penetration Testing Execution Standard，pentest-standard.org）：业内志愿者维护的渗透测试执行标准，覆盖前期交互、情报收集、威胁建模、漏洞分析、后渗透与报告等阶段