关基渗透测试实战检查清单：风险评估与加固合规性实战指南

基于《信息安全技术 关键信息基础设施安全测评要求（报批稿）》附录 B《渗透测试要求》整理，这份实战检查清单旨在为安全人员提供一套系统性的自查与评估框架。

进行关键信息基础设施的渗透测试，远不止于技术漏洞的发现，它是一套融合了流程管理、风险评估与合规验证的系统性工程。这份清单将帮助你从测试前准备到测试后收尾，全方位审视潜在的安全短板。

一、测试前通用检查

测试的成败，往往在开始前就已决定。充分的准备是安全、有效测试的基石。

• 明确测试目标、范围、边界、授权文件：确保所有行动均在合法合规的授权框架内进行。
• 确认测试环境：是实网、仿真环境还是桌面推演？不同环境的风险与策略截然不同。
• 确认不适合在生产环境直接验证的项目已切换到仿真或备机环境：避免测试行为对核心业务造成不可逆影响。
• 明确关键业务影响面，设置中止条件：一旦触及核心业务或可能引发服务中断，应有明确的熔断机制。
• 明确测试流程：信息收集、漏洞探测、漏洞验证、分析、报告，流程清晰方能有条不紊。
• 确认测试工具安全、合规：工具本身不应成为新的攻击入口或违规源头。
• 确认测试后遗留账号、规则、后门、样本、脚本可清理：确保测试活动“来去无痕”，不留下任何安全隐患。
• 约定高危发现的即时通报机制：发现即响应，降低潜在窗口期。
• 若获取管理员/系统控制权限，立即通知整改并按要求上报：权限的获取意味着风险的升级，必须立即处置。

---

二、通用测试项

1. 网络设备 / 安全设备

这是防御体系的第一道关卡，其自身安全至关重要。

• 1.1 公开安全漏洞
  • 是否存在已公开高危/中危漏洞？
  • 固件/版本是否过旧且存在可利用漏洞？
• 1.2 认证 / 授权
  • 是否存在默认口令、弱口令或相同口令复用？
  • 管理界面是否暴露在不应暴露的网络区域（如互联网）？
• 1.3 配置缺陷
  • 是否开放非必要端口或存在未声明的功能接口？
  • 是否存在远程调试接口未关闭或危险默认配置？

2. 操作系统

服务器与终端操作系统的安全是承载一切应用的基础。

• 2.1 公开安全漏洞
  • 是否存在已公开且可被利用的漏洞？
  • 系统补丁是否长期未更新？
• 2.2 认证 / 授权
  • 是否存在默认口令、弱口令或共用口令？
  • 是否存在认证绕过、权限配置不当（如不当的SUID/SGID文件）？
• 2.3 配置缺陷
  • 是否开放非必要端口或开启不必要的共享服务？
  • 是否因默认配置导致敏感信息泄露（如错误页面信息）？

3. 业务系统（WEB）

WEB应用是攻击面最广的入口之一，需进行多维度深度测试。

• 3.1 公开安全漏洞
  • WEB组件（中间件/框架/数据库/插件）是否存在公开漏洞？
• 3.2 信息泄露
  • 是否存在目录遍历、备份文件泄露、管理后台暴露？
  • 是否泄露路径、版本、详细报错信息？
  • 是否存在任意文件下载或明文口令传输？
• 3.3 配置缺陷
  • 是否缺失关键安全响应头（如CSP、HSTS）？
  • 跨域（CORS）配置是否过宽？
• 3.4 身份鉴别缺陷
  • 是否可绕过登录、存在未授权访问或越权访问？
  • 口令重置流程是否可被滥用？是否可暴力破解？
  • 是否可通过关键参数（如user_id）或IP伪造绕过限制？
• 3.5 逻辑设计缺陷
  • 是否存在业务流程绕过、任意步骤跳转或状态流转错误？
• 3.6 接口调用缺陷
  • 接口（尤其是API）是否存在访问控制缺陷？
  • 是否可枚举对象ID/资源ID？是否存在接口暴力攻击风险？
• 3.7 数据验证缺陷
  • 关键业务数据（如订单金额、库存）是否可被前端篡改？
  • 服务端是否缺失完整性/一致性校验？
• 3.8 综合利用 / 输入验证
  • 是否存在XSS、SQL注入、命令注入、表达式注入？
  • 是否存在任意文件上传、反序列化漏洞？

4. 业务系统（APP）

移动端安全需兼顾应用自身、业务逻辑与通信安全。

• 4.1 公开安全漏洞
  • APP本体及第三方SDK是否存在公开漏洞？
• 4.2 应用自身安全
  • 是否进行了有效的加固与混淆？
  • 第三方SDK与组件（含WeView）是否安全？
  • 是否严格校验证书？敏感数据是否明文存储或硬编码？
• 4.3 业务操作安全
  • 口令输入保护（防截屏、防录屏）是否充分？
  • 敏感信息（如身份证号、银行卡）展示是否合规（掩码）？
• 4.4 数据通信安全
  • 是否存在明文传输或重放攻击风险？
  • 通信协议设计是否存在缺陷？
• 4.5 服务端安全
  • 服务端是否已同步按WEB/系统侧要求完成安全测试？

5. 业务系统（C/S）

传统的客户端-服务器架构同样面临多样的安全挑战。

• 5.1 公开安全漏洞
  • 客户端或配套服务端组件是否存在已公开漏洞？
• 5.2 逆向保护
  • 程序是否易被反编译/逆向？是否存在硬编码的key/password？
  • 是否可提取加解密逻辑或绕过登录/权限判断？
• 5.3 信息泄露
  • 是否泄露敏感文件、注册表项、调试日志？
  • 安装包/运行目录或内存中是否残留敏感数据？
• 5.4 通信传输
  • 是否存在明文传输（FTP/TELNET/HTTP等）？
  • TLS/SSL配置是否不安全（弱加密套件、不安全握手）？
• 5.5 业务操作安全
  • 是否存在用户名枚举、暴力破解、弱口令问题？
  • 是否存在注入、遍历、XSS、SSRF、CSRF等WEB常见漏洞？
  • 是否存在未授权/越权、命令执行、业务流程绕过等问题？
• 5.6 软件安全
  • 是否存在DLL劫持、堆栈溢出、格式化字符串漏洞？
  • 是否存在DoS风险或任意地址写漏洞？

---

三、社工与其他风险

技术防御再坚固，人也可能是最薄弱的环节。

• 1. 撞库攻击
  • 是否可利用从其他渠道泄露的账号密码直接登录目标系统？
  • 身份认证机制是否薄弱，且缺乏有效的异常登录防护？
• 2. 钓鱼攻击
  • 通过邮件、短信、群聊等渠道发送的钓鱼链接/文件是否可能生效？
  • 相关人员是否具备足够的钓鱼识别能力？
  • 一旦钓鱼成功，后续的攻击链路是否可能导致关键账号泄露或终端失陷？
• 3. 假冒伪造
  • 是否可通过电话、即时通讯工具冒充内部人员或合作伙伴，诱导执行危险操作？
  • 是否可能骗取到敏感信息、验证码、口令或获得远程协助权限？

---

四、无线安全测试

无线网络边界模糊，是渗透内网的重要跳板。

• 是否可部署伪装（钓鱼）热点并诱导员工接入？
• 无线网络（WIFI）密码是否为弱口令？
• 是否仍在使用WEP等脆弱的加密方式？
• 是否可通过WPS PIN破解等方式绕过安全机制？
• 无线密码是否存在与其他系统口令撞库的风险？

---

五、新技术扩展测试

随着架构演进，攻击面也随之扩展。

1. 云计算安全（按实际采用情况选择）

• 1.1 云平台账号安全
  • 是否存在登录信息（AK/SK、控制台密码）泄露？
  • 是否存在账户劫持风险（如MFA绕过）？
• 1.2 云容器安全
  • 是否存在容器逃逸风险？
  • 容器间隔离是否不足？
• 1.3 云对象存储安全
  • Bucket是否错误配置为公开访问？
  • 是否可枚举Bucket/Object？存储策略配置是否存在错误？
  • 是否可任意上传/覆盖文件？
  • AccessKeyId / SecretAccessKey是否泄露在代码、日志或客户端？
  • 是否存在Bucket劫持或子域接管风险？
  • 是否可通过修改桶策略导致服务中断？
  • 是否可利用对象存储托管钓鱼页面？
• 1.4 云服务API安全
  • 云服务API是否存在配置错误或信息泄露？
  • 权限边界（如RAM策略）是否清晰，是否存在过度授权？

2. 移动互联安全（按实际采用情况选择）

• 2.1 物理接入
  • 办公无线热点是否存在未授权接入的可能？
  • 认证信息（如802.1X证书）是否存在被破解的风险？
• 2.2 移动终端
  • 移动终端（如通过VPN）接入后，是否可直接攻击内网敏感应用或数据？
  • 终端上的用户身份安全、数据保密性、网络边界完整性是否可靠？
  • App是否存在信息泄露、病毒木马、算法密钥泄露风险？
  • App是否可被反编译、动态调试、二次打包？
  • 是否存在业务逻辑缺陷、组件漏洞、数据漏洞？
  • 是否存在认证短信被劫持、自绘键盘被监听等问题？

3. 物联网安全（按实际采用情况选择）

• 3.1 公开安全漏洞
  • 物联网设备（摄像头、传感器、网关）是否存在已公开漏洞？
• 3.2 终端安全
  • 是否开放非必要端口（如Telnet、Debug端口）？
  • 嵌入式系统固件中是否泄露口令、证书私钥、源码？
  • 终端接入认证、接口访问控制、抗仿造、防篡改能力是否不足？
• 3.3 数据传输安全
  • 是否可发起中间人攻击并篡改通信数据包？
  • 是否存在敏感信息明文传输或使用不安全加密算法？
• 3.4 集权批量控制
  • 是否可通过攻陷一个后台控制系统来批量操控大量终端？
  • 是否可利用大量物联网设备发起DDoS攻击？
• 3.5 服务及应用安全
  • 设备管理WEB接口是否存在通用WEB漏洞？
  • 指令的抗重放机制是否完善？

4. 工业控制系统安全（按实际采用情况选择）

• 4.1 公开安全漏洞
  • 工控设备（PLC、RTU、HMI）是否存在已公开漏洞？
• 4.2 PLC漏洞测试（宜在备品备件环境进行）
  • 是否存在中间人攻击漏洞？
  • 是否存在未授权修改、覆盖程序或远程启停？
  • 是否存在功能码滥用、任意读写寄存器/线圈？
  • 是否存在计算逻辑漏洞、看门狗超时、缓冲区溢出？
• 4.3 工控协议漏洞测试
  • 工控协议（如Modbus、S7）是否存在明文传输敏感信息？
  • 协议身份认证机制是否不健全或缺失？
• 4.4 组态软件漏洞
  • 组态软件是否存在DoS、缓冲区溢出漏洞？
  • 是否存在COM服务组件未授权访问或SQL注入？
• 4.5 WEB接口漏洞
  • 设备WEB管理界面是否已按通用WEB测试项完成验证？

---

六、测试后检查

测试的结束，是整改的开始，也是安全闭环的关键。

• 已记录所有发现的问题、影响范围、利用条件和复现路径。
• 已根据风险高低，区分高危、中危、低危问题。
• 已对关键高危问题建立并执行了即时通报记录。
• 已彻底清理测试过程中创建的所有测试账号、后门、脚本、样本和临时策略。
• 已确认测试活动未对生产业务造成持续性影响或遗留风险。
• 已形成详实的渗透测试报告。
• 报告应包含具体的整改建议、修复优先级和复测方案。

---

七、建议的结果标记方式

为每一项检查结果添加以下标记，能使报告更具可操作性和可追溯性。

• 结果：通过 / 不通过 / 不适用
• 风险等级：高 / 中 / 低
• 证据：截图 / 日志 / 流量 / 命令输出 / 复现步骤
• 整改建议：立即修复 / 短期计划 / 中期规划

这份详尽的渗透测试检查清单，就像一份给关键信息基础设施的“全身体检表”。在实际使用中，安全团队可以根据自身业务特点和技术栈进行裁剪和补充。希望这份清单能帮助大家在复杂的网络攻防战中，建立起更系统、更深入的防御视角。如果你想就某个具体测试点展开讨论，或分享你的实践经验，欢迎来云栈社区的对应板块交流。