文章总结： 本文分享一次攻防打点实战经验，核心链路为递归扫描发现隐藏后台路径，通过请求包参数全局搜索挖掘出UserById接口获取密码，最终利用多文件头拼接绕过内容检测上传getshell。文章强调常规路径受阻时应切换至资产梳理模式，并给出具体操作步骤与授权测试建议。 综合评分： 85 文章分类： 渗透测试,红队,内网渗透,WEB安全,实战经验

第69篇 AI全栈 · 攻防打点-0day(信息泄漏)到getshell

原创

陈看山 陈看山

安全诸子

2026年9月4日 11:02 上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

打点阶段最痛苦的，不是目标系统有多硬，而是你花了两天把常规路径全走完，结果连一个像样的入口都没摸到。尤其是遇到 aspx 这种老技术栈的站点，爆破无果、前台 JS 翻了个底朝天也没有隐藏接口，这时候大部分人就开始怀疑是不是选错了目标。但真实攻防里，往往就是这种“难啃的骨头”反而藏着最典型的逻辑漏洞——不是利用难度高，而是藏得太深，需要靠递归扫描和请求包参数分析才能翻出来。

重新定义这次打点的核心矛盾

传统打点思路默认一个前提：漏洞应该出现在“功能入口”上，比如登录框、上传点、查询接口。但这次实际走通的路径完全绕开了这个前提——真正的突破口在被遗忘的后台地址和请求包中的参数泄露。

换句话说，这不是一个“漏洞利用链”的问题，而是一个信息资产梳理的问题。目标系统暴露的攻击面比你想象的大，但你用常规目录扫描和 JS 分析根本发现不了。递归扫描出来的 /abc/main.aspx 虽然会跳回首页，但它本身就是一个信号：这个路径是真实存在的，只是做了跳转防护。这时候如果放弃，就永远到不了下一步。

信息泄漏的核心矛盾在于：系统开发者默认“跳转”就等于“安全”，但跳转前的请求包、跳转后的响应头、以及跳转逻辑中携带的参数，都可能把内部信息带出来。 这次实战里，真正拿到密码的方式不是 SQL 注入，也不是暴力破解，而是从一个账号中心的请求包里发现了 action 参数，再通过全局搜索这些参数值，找到了 UserById 这个接口，直接返回了用户密码字段。

拆解攻击链的三个关键决策点

决策点一：什么时候该放弃常规路径

爆破无果、JS 无利用点，这两个结果其实已经告诉你：正面突破的成本很高。此时不应该继续耗在登录框上，而应该切换到资产测绘模式。递归扫描和常规目录扫描的区别在于，递归扫描会跟进每个目录下的子目录，能发现 /abc/ 这种嵌套路径，而常规扫描往往只扫第一层。

这一步的坑在于：很多人扫到 /abc/main.aspx 发现跳转首页就把它标记为“无效路径”。但正确的做法是尝试删除路径中的文件名，比如访问 /abc/ 或 /abc/main，看服务器是否返回不同的状态码。如果直接访问目录返回 403 或 200 但内容为空，说明这个目录是真实存在的，只是默认文档被配置了跳转。

决策点二：请求包参数是金矿

点击账号中心后抓到的数据请求包，表面上只有基础信息，但里面的 action 参数值才是关键。这里有个很容易被忽略的操作：用 Burp 的全局搜索功能去搜这些参数值。不要只搜 URL 或 cookie，要把请求体里的所有参数名和参数值都当成搜索词。

比如你看到 action=getUserInfo，那就去 Burp 的历史记录里搜 getUserInfo，看看有没有其他地方也调用了这个 action。如果搜到了，继续看它带了哪些参数。这次实战中，UserById 就是通过这种方式翻出来的，而且它接受一个用户 ID 参数，返回内容里直接包含了 pwd 字段。

决策点三：文件上传的绕过策略不是一次性的事

拿到后台权限之后，上传点往往是 getshell 的最短路径。但这次遇到的头像上传点不是简单的后缀名过滤，而是内容检测。常规的图片马直接改后缀会被拦，但实际测试发现用多文件头拼接的方式可以绕过。

具体逻辑是：服务端可能只校验文件的前 N 个字节是否为合法图片头，但不会校验整个文件内容。所以构造一个文件，头部是合法的 JPEG 头，中间夹着 ASP 一句话木马，尾部再补上 JPEG 结束标记。这种绕过方式测试起来很耗时，因为不同服务端的检测长度和检测位置都不一样，需要反复调整 payload 的位置和大小。

同类路径的对比参考

| 能力点 | 适合场景 | 接入成本 | 主要限制 | | — | — | — | — | | 递归目录扫描 | 常规路径无果、怀疑存在隐藏后台 | 低，工具本身免费 | 耗时长，可能产生大量噪音请求 | | 请求包参数全局搜索 | 已获取部分业务接口、需要横向扩展攻击面 | 低，Burp 自带功能 | 依赖历史流量积累，新环境效果差 | | 多文件头拼接绕过 | 遇到内容检测型上传点 | 中，需要反复测试 | 对检测严格的 WAF 无效 | | 任意密码读取接口挖掘 | 后台登录凭据未知、存在用户查询类功能 | 中，需手工分析参数 | 接口可能做了权限校验，需配合越权测试 |

真实限制与接入成本

基于当前可见信息，这条路径有几个前提条件需要明确：

第一，递归扫描的代价是时间。 如果目标站点的目录结构很深，递归扫描可能跑几小时甚至一天。而且扫描产生的请求量可能会触发 WAF 的速率限制，导致后续操作被封 IP。建议在扫描前先确认目标是否部署了 WAF，如果有，需要降低线程数或改用慢速扫描模式。

第二，参数全局搜索依赖流量样本。 如果 Burp 的历史记录里没有足够的接口调用数据，全局搜索就无从谈起。这意味着你需要在目标站点上尽可能多地点击功能点，制造流量。这一步容易被忽略，但它是后续所有分析的基础。

第三，内容检测上传点的绕过具有高度不确定性。 这次测试的多文件头拼接方法，在另一个站点上可能完全无效。因为服务端可能是用 getimagesize() 校验整个文件，也可能是用 exif_imagetype() 只读文件头。你没法提前知道检测逻辑，只能靠不断测试来逼近。

这条路不适合以下情况： 目标系统是纯前端 SPA 应用、所有接口都走 GraphQL 且做了严格的 schema 校验、或者目标部署了商业级 WAF 并且规则更新及时。在这些场景下，上述方法要么找不到突破口，要么会被直接拦截。

怎么接入你自己的打点流程

如果你现在正准备做一次授权测试或靶场演练，可以按这个顺序操作：

第一步，把常规路径的时间盒设为一个固定值，比如两小时。两小时内爆破无果、JS 分析无果，立刻切换到递归扫描。不要恋战。

第二步，递归扫描发现可疑路径后，不要只关注 200 状态码的页面。403、500、302 跳转的路径都要手动访问一遍，尝试删掉路径末尾的文件名，直接访问目录，观察服务器行为差异。

第三步，进入任何需要登录或半登录状态的功能页面，把数据请求包完整保存下来。不要只看响应内容，重点分析请求体的参数结构。将每个参数名和值都放进 Burp 的全局搜索列表。

第四步，如果通过参数搜索发现了类似 getUserById、queryUserInfo 这类接口，先测试未授权访问。如果返回了密码或敏感字段，直接尝试登录后台。如果提示权限不足，再尝试修改参数中的 ID 值，做越权测试。

第五步，上传点测试时，先探测服务端校验的是后缀名、MIME 类型还是文件内容。探测方法很简单：上传一个正常的图片，再上传一个改了后缀的图片马，观察拦截情况。如果改了后缀被拦，说明校验的是后缀；如果放了但访问 500，说明校验的是内容。

给读者的实践建议

这次攻防打点的完整链路——从递归扫描发现隐藏路径，到请求包参数分析拿到密码，再到内容检测绕过后 getshell——本质上是在回答一个问题：当正面突破成本过高时，你愿不愿意花时间去翻那些没人注意的角落？

建议你在下一次授权测试中，刻意给自己设一个规则：常规路径只花三分之一的时间，另外三分之二的时间全部投入在资产梳理和信息分析上。你会发现，大多数系统的问题不是出在漏洞利用的难度，而是出在开发者留下了太多“自以为安全”的接口和路径。

最后提醒一句：以上所有操作必须在获得合法授权的前提下进行，未经授权对目标系统发起测试是违法行为。如果你是在学习这些技术，建议在本地搭建靶场环境，或者使用公开的漏洞靶场平台进行练习。把这条攻击链在靶场上完整跑通一遍，比看十篇文章都管用。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全诸子 陈看山 陈看山《第69篇 AI全栈 · 攻防打点-0day(信息泄漏)到getshell》