系列导读第1期我们聊了SRC是什么、新手为什么适合从SRC入门第2期我们搭建了完整的测试环境Burp Suite 独立浏览器 本地靶场。今天第3期我们进入真正的实战环节——在合规靶场上完成一次完整的漏洞分析流程从信息收集到漏洞验证全流程走一遍。很多新手读完前两期后问得最多的问题是“环境搭好了Burp也能抓包了但我不知道往哪里看、看什么、怎么判断是不是漏洞。”这个问题非常普遍。工具只是眼睛让你看到请求和响应分析能力才是大脑帮你判断‘这里有没有问题’。今天我们就用Pikachu靶场一个国产中文漏洞练习平台作为演示目标完整走一遍从“打开网页”到“写出漏洞报告”的全过程。全程在本地环境操作零风险、可复现你可以一边读一边跟着做。一、本次实战的“授权边界”说明在真实SRC场景中第一步永远是确认授权范围。为了演示我们本次使用本地靶场目标地址http://127.0.0.1:8081/pikachu本地环境授权状态完全授权本地自有环境任意操作测试账号使用靶场自带的测试账号admin/123456如果你还没有部署Pikachu可以用Docker一键拉起bashdocker pull area39/pikachu docker run -d -p 8081:80 area39/pikachu访问http://127.0.0.1:8081/pikachu点击“初始化/重置”即可开始。二、第一阶段信息收集不扫描、不发包只看“表面”很多新手拿到目标后第一件事就是打开Burp开始抓包或者直接上扫描器。这其实是低效的做法。正确顺序是先用手和眼睛做一遍“表面信息收集”搞清楚目标的基本情况再决定从哪个方向深入。1. 打开目标网站观察页面结构用配置好的专用浏览器配置了代理、安装了Wappalyzer访问http://127.0.0.1:8081/pikachu。肉眼观察清单观察维度你看到了什么记录什么顶部导航栏“首页”“SQL注入”“XSS”“CSRF”等导航分类功能模块分布登录/注册入口右上角有“登录”和“注册”存在用户认证功能页面底部版权信息、版本号可能暴露技术栈版本URL格式http://127.0.0.1:8081/pikachu/index.php后端语言是PHPURL中的参数点击“SQL注入” → URL变为.../sqli.php不同的功能对应不同的PHP文件此时不必打开Burp只需用浏览器DevToolsF12看一下Network面板刷新页面观察加载了哪些资源主页面index.phpCSS文件style.cssJS文件js/main.js图片资源images/logo.png记录结论后端PHP从.php后缀推断前端简单HTML CSS 原生JavaScript主要功能点登录、注册、SQL注入靶场、XSS靶场、CSRF靶场、文件上传靶场2. 使用Wappalyzer识别公开技术栈Wappalyzer会告诉你目标使用了哪些前端/后端/服务器技术。在本次演示中它会显示Web服务器Apache编程语言PHP操作系统LinuxDocker环境这些信息本身不构成漏洞但可以帮助你在后续分析中缩小排查范围——比如知道是PHP环境后可以重点关注PHP常见漏洞类型文件包含、反序列化等。3. 信息收集阶段总结新手常犯错误信息收集阶段就打开Burp抓包试图把所有请求都录下来。这样会导致大量冗余数据真正需要关注的关键请求反而被淹没了。正确做法先用浏览器浏览页面结构用F12 Network筛选出关键接口登录请求、数据查询请求、表单提交请求再针对性地用Burp分析。三、第二阶段选择目标接口开始抓包分析信息收集完成后你已经对目标有了基本了解。接下来选择一个具体的功能点作为切入点——不要试图一次性分析整个网站。对于新手我强烈建议从“登录接口”或“查询接口”开始因为它们最容易被忽视也最容易出现基础漏洞。选择切入点登录功能本次我们选择Pikachu的“登录”功能在右上角。操作步骤打开Burp Suite确认Proxy → Intercept处于Intercept is off状态避免拦截影响正常操作在浏览器中进入登录页面输入测试账号admin、密码123456点击登录登录完成后回到Burp → Proxy → HTTP history找到登录请求。如何找到正确的请求按时间排序找最新的几条通过请求路径筛选/pikachu/login.php或类似的路径看请求方法通常是POST登录一般用POST看请求体包含usernameadminpassword123456的内容就是登录请求。分析这个登录请求我们找到了一个典型的登录请求httpPOST /pikachu/login.php HTTP/1.1 Host: 127.0.0.1:8081 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Content-Type: application/x-www-form-urlencoded Content-Length: 30 usernameadminpassword123456响应返回httpHTTP/1.1 200 OK Set-Cookie: PHPSESSIDabc123def456; path/ Content-Type: text/html; charsetUTF-8 {code:0,msg:登录成功}这时候你要思考什么思考维度具体问题请求参数只有username和password两个参数没有验证码、没有token响应信息返回了“登录成功”的明确消息并且code0表示成功Cookie登录后设置了PHPSESSID说明后端使用Session管理会话错误响应如果密码错误返回的是{code:1,msg:用户名或密码错误}这时你已经发现了一个潜在问题登录失败和登录成功的响应差异非常明确攻击者可以通过枚举用户名观察响应差异来判断某个账号是否存在——这就是用户名枚举漏洞。四、第三阶段在Repeater中验证漏洞发现了可疑点后下一步是在Repeater中做最小化验证——不要直接在浏览器里反复试用Burp Repeater更可控、更干净。操作步骤在HTTP history中找到登录请求右键 → Send to Repeater切换到Repeater面板修改请求参数观察响应变化。验证测试1用户名枚举测试用例请求体响应判断正确用户名正确密码usernameadminpassword123456{code:0,msg:登录成功}正常正确用户名错误密码usernameadminpasswordwrong{code:1,msg:用户名或密码错误}⚠️ 提示“用户名或密码错误”错误用户名任意密码usernamenotexistpassword123456{code:1,msg:用户名或密码错误}⚠️ 同样提示“用户名或密码错误”分析在这个靶场中错误用户名和正确用户名错误密码的响应完全一致所以不存在用户名枚举漏洞——这是一次成功的“排除测试”。注意很多人以为只有“发现漏洞”才是收获其实“确认没有漏洞”同样是分析能力的体现。在真实SRC中你也会遇到大量“看上去像漏洞但实际不是”的情况学会排除也是一种进步。验证测试2弱口令既然登录功能没有用户名枚举我们再试试另一个常见的风险点弱口令。在浏览器中尝试以下组合用户名密码结果admin123456✅ 登录成功adminadmin❌ 失败admin123123❌ 失败admin12345678❌ 失败在这个靶场中只有123456能登录成功没有其他弱口令问题。但请注意真实SRC场景中弱口令是非常高频的有效漏洞尤其是admin/123456、admin/admin、test/test等常见组合。五、第四阶段深入挖掘——SQL注入漏洞登录功能没有发现有效漏洞我们换一个方向。Pikachu的导航栏中有一个“SQL注入”板块我们点进去看看。信息收集针对该子功能进入“SQL注入”页面后发现有一个输入框提示“请输入用户ID查询信息”。输入1点击查询页面显示用户admin的详细信息输入2显示用户test的信息URL中没有参数说明数据是通过POST表单提交的。打开Burp HTTP history找到这个查询请求httpPOST /pikachu/sqli.php HTTP/1.1 Host: 127.0.0.1:8081 Content-Type: application/x-www-form-urlencoded Content-Length: 6 id1响应中返回了用户信息说明后端根据id参数从数据库查询数据。验证SQL注入在Repeater中测试测试用例请求体响应特征正常参数id1返回用户admin信息添加单引号id1❌ 页面报错出现SQL语法错误注释后引号id1 --✅ 正常返回用户admin信息第二条测试出现SQL报错这是非常强烈的信号——说明后端直接将用户输入拼接到SQL语句中且没有做任何过滤或参数化处理。再测试一个经典的布尔盲注payload测试用例请求体响应条件为真id1 and 11✅ 正常返回用户信息条件为假id1 and 12❌ 无返回结果两者响应不同说明存在SQL注入漏洞且可以通过布尔盲注的方式提取数据。⚠️ 验证阶段的重要原则在真实SRC场景中证明漏洞存在即可不要进一步提取数据。具体来说✅ 通过1 and 11vs1 and 12的响应差异证明注入存在✅ 通过1 OR 11观察是否返回了所有用户数据❌不要使用UNION SELECT提取数据库中的真实数据❌不要使用sqlmap进行自动化数据导出。我们是在本地靶场所以可以做更多测试来学习。但在真实SRC中点到为止证明即可。六、第五阶段编写完整的漏洞报告现在我们已经确认了一个SQL注入漏洞。接下来按照第2期讲到的报告结构完整写一份报告。漏洞报告模板本案例markdown## 漏洞标题 Pikachu靶场SQL注入模块存在布尔盲注漏洞 ## 漏洞类型 SQL注入布尔盲注 ## 危害等级 中危本地靶场演示真实场景中根据数据库权限和数据类型定级 ## 漏洞URL http://127.0.0.1:8081/pikachu/sqli.php ## 漏洞描述 在SQL注入功能模块中用户输入的id参数未经过滤直接拼接到SQL查询语句中攻击者可通过构造布尔条件判断语句获取数据库中的敏感信息。 ## 复现步骤 ### 环境准备 - 浏览器Chrome 120专用测试配置文件 - 工具Burp Suite Community Edition - 目标地址http://127.0.0.1:8081/pikachu/sqli.php ### 步骤1正常请求 发送POST请求POST /pikachu/sqli.php HTTP/1.1Host: 127.0.0.1:8081Content-Type: application/x-www-form-urlencodedid1text响应正常返回用户名为admin的用户信息。 ### 步骤2注入单引号 发送请求POST /pikachu/sqli.php HTTP/1.1Host: 127.0.0.1:8081Content-Type: application/x-www-form-urlencodedid1text页面返回SQL语法错误说明输入被直接拼接到SQL语句中。 ### 步骤3布尔盲注验证 - 条件为真 发送请求POST /pikachu/sqli.php HTTP/1.1Host: 127.0.0.1:8081Content-Type: application/x-www-form-urlencodedid1 and 11text响应正常返回用户信息。 ### 步骤4布尔盲注验证 - 条件为假 发送请求POST /pikachu/sqli.php HTTP/1.1Host: 127.0.0.1:8081Content-Type: application/x-www-form-urlencodedid1 and 12text响应为空无用户信息返回。 ### 步骤5结论 条件为真和条件为假的响应存在明确差异确认存在SQL布尔盲注漏洞。 ## 漏洞危害 攻击者可通过布尔盲注方式逐字符提取数据库中的表名、字段名、用户名、密码等信息造成敏感数据泄露。 ## 修复建议 1. 使用参数化查询Prepared Statement处理用户输入 2. 对用户输入进行严格的类型校验id参数应仅允许整数类型 3. 关闭数据库错误回显避免暴露SQL语法细节。 ## 测试环境 - 操作系统Windows 11 / macOS 13 - 浏览器Chrome 120 - 测试工具Burp Suite Community Edition v2023.12 - 目标环境本地Docker部署的Pikachu靶场七、本次实战总结你学到了什么回顾一下本次完整的漏洞分析流程阶段核心动作关键产出信息收集浏览页面、F12 Network、Wappalyzer了解技术栈、功能模块分布选择切入点从登录接口入手缩小分析范围明确首个分析目标抓包分析用Burp HTTP history找到关键请求理解请求/响应结构Repeater验证修改参数观察响应差异确认/排除漏洞疑点深入挖掘切换到SQL注入模块测试注入Payload确认漏洞存在编写报告按结构整理复现步骤和证据产出可提交的漏洞报告这6个阶段是通用的SRC漏洞挖掘工作流。无论你面对的是什么目标都可以按这个顺序推进。八、下期预告 行动清单下期预告第4期《新手最容易挖到的3类漏洞信息泄露、弱口令与越权》我们将从这3个高频低门槛的漏洞类型入手给你一套可以直接套用的检测思路和验证方法。看完本文后请完成以下练习□在本地Pikachu靶场的XSS模块中尝试找到存储型XSS漏洞并写一份完整的漏洞报告□在Pikachu的CSRF模块中分析修改密码请求尝试构造CSRF Poc□把你写好的报告发给身边的朋友或社群让他们帮你挑刺哪里写得不够清晰、哪里复现步骤缺失。声明本文内容仅供网络安全学习与技术交流所有操作已在本地靶场中完成。未经授权对他人系统进行测试属于违法行为请自觉遵守法律法规及平台规则。本文不提供任何自动化攻击工具或攻击代码。
【SRC漏洞挖掘系列·第3期】第一次漏洞分析：从信息收集到合规靶场验证，手把手走一遍
系列导读第1期我们聊了SRC是什么、新手为什么适合从SRC入门第2期我们搭建了完整的测试环境Burp Suite 独立浏览器 本地靶场。今天第3期我们进入真正的实战环节——在合规靶场上完成一次完整的漏洞分析流程从信息收集到漏洞验证全流程走一遍。很多新手读完前两期后问得最多的问题是“环境搭好了Burp也能抓包了但我不知道往哪里看、看什么、怎么判断是不是漏洞。”这个问题非常普遍。工具只是眼睛让你看到请求和响应分析能力才是大脑帮你判断‘这里有没有问题’。今天我们就用Pikachu靶场一个国产中文漏洞练习平台作为演示目标完整走一遍从“打开网页”到“写出漏洞报告”的全过程。全程在本地环境操作零风险、可复现你可以一边读一边跟着做。一、本次实战的“授权边界”说明在真实SRC场景中第一步永远是确认授权范围。为了演示我们本次使用本地靶场目标地址http://127.0.0.1:8081/pikachu本地环境授权状态完全授权本地自有环境任意操作测试账号使用靶场自带的测试账号admin/123456如果你还没有部署Pikachu可以用Docker一键拉起bashdocker pull area39/pikachu docker run -d -p 8081:80 area39/pikachu访问http://127.0.0.1:8081/pikachu点击“初始化/重置”即可开始。二、第一阶段信息收集不扫描、不发包只看“表面”很多新手拿到目标后第一件事就是打开Burp开始抓包或者直接上扫描器。这其实是低效的做法。正确顺序是先用手和眼睛做一遍“表面信息收集”搞清楚目标的基本情况再决定从哪个方向深入。1. 打开目标网站观察页面结构用配置好的专用浏览器配置了代理、安装了Wappalyzer访问http://127.0.0.1:8081/pikachu。肉眼观察清单观察维度你看到了什么记录什么顶部导航栏“首页”“SQL注入”“XSS”“CSRF”等导航分类功能模块分布登录/注册入口右上角有“登录”和“注册”存在用户认证功能页面底部版权信息、版本号可能暴露技术栈版本URL格式http://127.0.0.1:8081/pikachu/index.php后端语言是PHPURL中的参数点击“SQL注入” → URL变为.../sqli.php不同的功能对应不同的PHP文件此时不必打开Burp只需用浏览器DevToolsF12看一下Network面板刷新页面观察加载了哪些资源主页面index.phpCSS文件style.cssJS文件js/main.js图片资源images/logo.png记录结论后端PHP从.php后缀推断前端简单HTML CSS 原生JavaScript主要功能点登录、注册、SQL注入靶场、XSS靶场、CSRF靶场、文件上传靶场2. 使用Wappalyzer识别公开技术栈Wappalyzer会告诉你目标使用了哪些前端/后端/服务器技术。在本次演示中它会显示Web服务器Apache编程语言PHP操作系统LinuxDocker环境这些信息本身不构成漏洞但可以帮助你在后续分析中缩小排查范围——比如知道是PHP环境后可以重点关注PHP常见漏洞类型文件包含、反序列化等。3. 信息收集阶段总结新手常犯错误信息收集阶段就打开Burp抓包试图把所有请求都录下来。这样会导致大量冗余数据真正需要关注的关键请求反而被淹没了。正确做法先用浏览器浏览页面结构用F12 Network筛选出关键接口登录请求、数据查询请求、表单提交请求再针对性地用Burp分析。三、第二阶段选择目标接口开始抓包分析信息收集完成后你已经对目标有了基本了解。接下来选择一个具体的功能点作为切入点——不要试图一次性分析整个网站。对于新手我强烈建议从“登录接口”或“查询接口”开始因为它们最容易被忽视也最容易出现基础漏洞。选择切入点登录功能本次我们选择Pikachu的“登录”功能在右上角。操作步骤打开Burp Suite确认Proxy → Intercept处于Intercept is off状态避免拦截影响正常操作在浏览器中进入登录页面输入测试账号admin、密码123456点击登录登录完成后回到Burp → Proxy → HTTP history找到登录请求。如何找到正确的请求按时间排序找最新的几条通过请求路径筛选/pikachu/login.php或类似的路径看请求方法通常是POST登录一般用POST看请求体包含usernameadminpassword123456的内容就是登录请求。分析这个登录请求我们找到了一个典型的登录请求httpPOST /pikachu/login.php HTTP/1.1 Host: 127.0.0.1:8081 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Content-Type: application/x-www-form-urlencoded Content-Length: 30 usernameadminpassword123456响应返回httpHTTP/1.1 200 OK Set-Cookie: PHPSESSIDabc123def456; path/ Content-Type: text/html; charsetUTF-8 {code:0,msg:登录成功}这时候你要思考什么思考维度具体问题请求参数只有username和password两个参数没有验证码、没有token响应信息返回了“登录成功”的明确消息并且code0表示成功Cookie登录后设置了PHPSESSID说明后端使用Session管理会话错误响应如果密码错误返回的是{code:1,msg:用户名或密码错误}这时你已经发现了一个潜在问题登录失败和登录成功的响应差异非常明确攻击者可以通过枚举用户名观察响应差异来判断某个账号是否存在——这就是用户名枚举漏洞。四、第三阶段在Repeater中验证漏洞发现了可疑点后下一步是在Repeater中做最小化验证——不要直接在浏览器里反复试用Burp Repeater更可控、更干净。操作步骤在HTTP history中找到登录请求右键 → Send to Repeater切换到Repeater面板修改请求参数观察响应变化。验证测试1用户名枚举测试用例请求体响应判断正确用户名正确密码usernameadminpassword123456{code:0,msg:登录成功}正常正确用户名错误密码usernameadminpasswordwrong{code:1,msg:用户名或密码错误}⚠️ 提示“用户名或密码错误”错误用户名任意密码usernamenotexistpassword123456{code:1,msg:用户名或密码错误}⚠️ 同样提示“用户名或密码错误”分析在这个靶场中错误用户名和正确用户名错误密码的响应完全一致所以不存在用户名枚举漏洞——这是一次成功的“排除测试”。注意很多人以为只有“发现漏洞”才是收获其实“确认没有漏洞”同样是分析能力的体现。在真实SRC中你也会遇到大量“看上去像漏洞但实际不是”的情况学会排除也是一种进步。验证测试2弱口令既然登录功能没有用户名枚举我们再试试另一个常见的风险点弱口令。在浏览器中尝试以下组合用户名密码结果admin123456✅ 登录成功adminadmin❌ 失败admin123123❌ 失败admin12345678❌ 失败在这个靶场中只有123456能登录成功没有其他弱口令问题。但请注意真实SRC场景中弱口令是非常高频的有效漏洞尤其是admin/123456、admin/admin、test/test等常见组合。五、第四阶段深入挖掘——SQL注入漏洞登录功能没有发现有效漏洞我们换一个方向。Pikachu的导航栏中有一个“SQL注入”板块我们点进去看看。信息收集针对该子功能进入“SQL注入”页面后发现有一个输入框提示“请输入用户ID查询信息”。输入1点击查询页面显示用户admin的详细信息输入2显示用户test的信息URL中没有参数说明数据是通过POST表单提交的。打开Burp HTTP history找到这个查询请求httpPOST /pikachu/sqli.php HTTP/1.1 Host: 127.0.0.1:8081 Content-Type: application/x-www-form-urlencoded Content-Length: 6 id1响应中返回了用户信息说明后端根据id参数从数据库查询数据。验证SQL注入在Repeater中测试测试用例请求体响应特征正常参数id1返回用户admin信息添加单引号id1❌ 页面报错出现SQL语法错误注释后引号id1 --✅ 正常返回用户admin信息第二条测试出现SQL报错这是非常强烈的信号——说明后端直接将用户输入拼接到SQL语句中且没有做任何过滤或参数化处理。再测试一个经典的布尔盲注payload测试用例请求体响应条件为真id1 and 11✅ 正常返回用户信息条件为假id1 and 12❌ 无返回结果两者响应不同说明存在SQL注入漏洞且可以通过布尔盲注的方式提取数据。⚠️ 验证阶段的重要原则在真实SRC场景中证明漏洞存在即可不要进一步提取数据。具体来说✅ 通过1 and 11vs1 and 12的响应差异证明注入存在✅ 通过1 OR 11观察是否返回了所有用户数据❌不要使用UNION SELECT提取数据库中的真实数据❌不要使用sqlmap进行自动化数据导出。我们是在本地靶场所以可以做更多测试来学习。但在真实SRC中点到为止证明即可。六、第五阶段编写完整的漏洞报告现在我们已经确认了一个SQL注入漏洞。接下来按照第2期讲到的报告结构完整写一份报告。漏洞报告模板本案例markdown## 漏洞标题 Pikachu靶场SQL注入模块存在布尔盲注漏洞 ## 漏洞类型 SQL注入布尔盲注 ## 危害等级 中危本地靶场演示真实场景中根据数据库权限和数据类型定级 ## 漏洞URL http://127.0.0.1:8081/pikachu/sqli.php ## 漏洞描述 在SQL注入功能模块中用户输入的id参数未经过滤直接拼接到SQL查询语句中攻击者可通过构造布尔条件判断语句获取数据库中的敏感信息。 ## 复现步骤 ### 环境准备 - 浏览器Chrome 120专用测试配置文件 - 工具Burp Suite Community Edition - 目标地址http://127.0.0.1:8081/pikachu/sqli.php ### 步骤1正常请求 发送POST请求POST /pikachu/sqli.php HTTP/1.1Host: 127.0.0.1:8081Content-Type: application/x-www-form-urlencodedid1text响应正常返回用户名为admin的用户信息。 ### 步骤2注入单引号 发送请求POST /pikachu/sqli.php HTTP/1.1Host: 127.0.0.1:8081Content-Type: application/x-www-form-urlencodedid1text页面返回SQL语法错误说明输入被直接拼接到SQL语句中。 ### 步骤3布尔盲注验证 - 条件为真 发送请求POST /pikachu/sqli.php HTTP/1.1Host: 127.0.0.1:8081Content-Type: application/x-www-form-urlencodedid1 and 11text响应正常返回用户信息。 ### 步骤4布尔盲注验证 - 条件为假 发送请求POST /pikachu/sqli.php HTTP/1.1Host: 127.0.0.1:8081Content-Type: application/x-www-form-urlencodedid1 and 12text响应为空无用户信息返回。 ### 步骤5结论 条件为真和条件为假的响应存在明确差异确认存在SQL布尔盲注漏洞。 ## 漏洞危害 攻击者可通过布尔盲注方式逐字符提取数据库中的表名、字段名、用户名、密码等信息造成敏感数据泄露。 ## 修复建议 1. 使用参数化查询Prepared Statement处理用户输入 2. 对用户输入进行严格的类型校验id参数应仅允许整数类型 3. 关闭数据库错误回显避免暴露SQL语法细节。 ## 测试环境 - 操作系统Windows 11 / macOS 13 - 浏览器Chrome 120 - 测试工具Burp Suite Community Edition v2023.12 - 目标环境本地Docker部署的Pikachu靶场七、本次实战总结你学到了什么回顾一下本次完整的漏洞分析流程阶段核心动作关键产出信息收集浏览页面、F12 Network、Wappalyzer了解技术栈、功能模块分布选择切入点从登录接口入手缩小分析范围明确首个分析目标抓包分析用Burp HTTP history找到关键请求理解请求/响应结构Repeater验证修改参数观察响应差异确认/排除漏洞疑点深入挖掘切换到SQL注入模块测试注入Payload确认漏洞存在编写报告按结构整理复现步骤和证据产出可提交的漏洞报告这6个阶段是通用的SRC漏洞挖掘工作流。无论你面对的是什么目标都可以按这个顺序推进。八、下期预告 行动清单下期预告第4期《新手最容易挖到的3类漏洞信息泄露、弱口令与越权》我们将从这3个高频低门槛的漏洞类型入手给你一套可以直接套用的检测思路和验证方法。看完本文后请完成以下练习□在本地Pikachu靶场的XSS模块中尝试找到存储型XSS漏洞并写一份完整的漏洞报告□在Pikachu的CSRF模块中分析修改密码请求尝试构造CSRF Poc□把你写好的报告发给身边的朋友或社群让他们帮你挑刺哪里写得不够清晰、哪里复现步骤缺失。声明本文内容仅供网络安全学习与技术交流所有操作已在本地靶场中完成。未经授权对他人系统进行测试属于违法行为请自觉遵守法律法规及平台规则。本文不提供任何自动化攻击工具或攻击代码。