网站命令执行渗透测试是检验Web应用安全性的重要手段，核心目标是确认目标站点是否允许未经充分过滤的用户输入被当作系统命令执行。此类漏洞一旦存在，攻击者便可借此读取服务器文件、反弹shell甚至控制整台主机。因此，按照规范流程开展测试，对保障业务安全具有实际意义。
一、测试前的信息收集与目标确认
在动手测试之前，必须先明确授权范围和目标系统边界。未经书面授权的渗透测试属于违法行为，所以第一步应是获取客户或上级的安全测试许可，确定待测域名、IP段以及可接受的测试时间窗口。同时，整理目标站点的功能清单，重点标记那些可能调用系统命令的模块，例如ping检测、文件格式转换、邮件发送、系统工具调用等页面。
信息收集阶段还要借助扫描器与手动探测结合的方式，识别目标使用的Web框架、中间件版本及操作系统类型。比如通过HTTP响应头、错误页面特征、特定路径探测，可以大致判断其为Nginx加PHP环境还是IIS加ASP.NET环境。这些底层信息将直接影响后续命令执行payload的构造方式，因为不同系统支持的命令语法和分隔符存在差异。
二、漏洞探测与入口定位
命令执行漏洞常出现在接收用户输入并拼接到系统调用函数的位置。测试人员可在疑似功能点提交特殊构造的参数，观察响应变化。例如在一个网络诊断页面输入IP地址处，尝试提交“127.0.0.1;id”或“127.0.0.1&&whoami”，若返回结果中出现了当前用户身份而非单纯的ping回显，就说明可能存在命令拼接执行问题。
除了显式注入，还要关注一些隐式入口，如User-Agent、Cookie、上传文件名称等HTTP头或元数据，某些后端逻辑会将这些字段拼入exec类函数。探测时建议使用延时指令（如sleep 5）做盲注判断，若页面响应时间明显增加，则证明命令被后端执行但结果未直接回显。此时需要记录请求特征，为后续利用做准备。
三、漏洞利用与权限验证
确认漏洞存在后，下一步是验证其可利用程度。在授权环境中，可尝试执行无害指令获取系统基本信息，如“uname -a”查看内核版本，“cat /etc/passwd”确认用户结构。若目标过滤了空格，可用“${IFS}”或制表符替代；若禁止了常见命令字，可通过变量拼接或base64解码方式绕过，例如“echo d2hvYW1p|base64 -d|sh”来间接执行whoami。
为了向客户直观证明风险，可进一步建立低权限交互shell，但严禁在业务高峰期或生产库服务器做高危操作。利用成功后应截图保存证据，并记录命令执行上下文权限。如果当前为普通web用户，可留意是否存在sudo配置不当或内核漏洞以便提权，不过提权测试需格外谨慎，避免破坏系统稳定性。
四、结果记录与修复建议
测试收尾时，需将每一步请求包、响应特征、利用截图整理成报告。表格化呈现有助于开发人员快速理解问题严重性：
| 风险项 | 发现位置 | 影响等级 | 临时处置 |
|---|---|---|---|
| 命令拼接执行 | /diag/ping.php | 高危 | 暂停该功能 |
| 头信息命令注入 | User-Agent处理 | 中危 | 过滤特殊字符 |
针对命令执行漏洞，根本修复方案是避免直接调用系统命令，改用语言内置的安全API实现同等功能。若必须调用，应使用白名单校验输入、用数组传参方式调用exec且禁止shell解释、并最小化web服务账户权限。上线前还应加入自动化安全扫描，防止类似缺陷再次流入生产环境。
五、注意事项与合规边界
整个渗透测试过程必须控制在授权范围内，不得借助发现的漏洞访问无关数据或横向移动至其他非约定系统。测试结束后要及时清理自己创建的可疑文件与计划任务，恢复目标环境原状。只有将技术操作与合规要求结合，网站命令执行渗透测试才能既发现问题又规避法律风险。
此外，建议企业每年定期开展此类专项测试，并将结果纳入安全考核。因为攻击手法不断演化，今日安全的配置可能在引入新组件后再次出现命令执行弱点，持续验证才是稳健防护的关键。