一、 测试前：规划与准备阶段
这个阶段决定了渗透测试的合法性、范围和有效性。
明确授权，获取书面许可
核心原则：没有授权，就是攻击。
必须与客户或产品负责人签署详细的《渗透测试授权书》，明确测试范围、时间、方式以及免责条款。这是保护测试方和被测方的法律基础。
精准定义测试范围
黑盒测试：模拟真实黑客，无任何内部信息。侧重于外部威胁。
白盒测试：提供源代码、架构图等全部信息。能更深入、高效地发现逻辑和深层漏洞。
灰盒测试：提供部分信息（如低权限账户）。平衡效率和真实性。
系统范围：明确测试哪些系统、IP地址、域名、网络段。是测试Web应用、移动应用（Android/iOS）、API接口、还是整个内网？
测试类型：明确采用哪种测试方式：
排除范围：明确哪些系统或测试手法是禁止的（例如，禁止对核心数据库进行DDos攻击）。
设定目标与成功标准
与利益相关者沟通，明确测试的目标。是为了满足合规性（如等保2.0、PCI-DSS）？还是为了发现潜在业务风险？或是评估新功能的安全性？
定义什么是“成功”的测试，例如：获取特定敏感数据、证明可完全控制系统、发现超过X个高危漏洞等。
制定详细的测试计划
包括时间表、人员分工、沟通机制（如每日站会）、应急响应流程（如果测试导致系统崩溃该怎么办）。
信息收集与工具准备
根据测试类型，尽可能多地收集目标信息（域名、技术栈、框架、第三方组件等）。
准备好渗透测试工具集（如Burp Suite, Nmap, Metasploit, SQLMap等），并确保其更新到最新版本。
二、 测试中：执行与监控阶段
这个阶段是核心的技术执行过程，需要严谨和细致。
遵守范围与规则
严格在授权范围内操作，绝不越界。任何超出范围的探索都必须先获得额外授权。
遵守约定的测试时间窗口，避免在业务高峰期进行可能影响系统稳定的测试。
注意测试手法的影响
谨慎使用自动化工具：像SQLMap、漏洞扫描器这类工具可能产生大量请求，对服务器造成压力，甚至可能破坏数据。在测试环境中可大胆使用，在生产环境需极其小心。
避免破坏性操作：原则上“只证明，不破坏”。对于写入、删除等操作，除非获得明确许可并有完备的数据备份，否则应避免。
注意社会工程学测试的伦理：如果涉及对人员的测试，必须提前获得高级管理层的批准，并注意方式方法，避免对员工造成心理伤害。
深度优先于广度
越权操作（水平越权、垂直越权）
业务流程绕过（如跳过支付步骤）
竞争条件漏洞
接口参数篡改
不要满足于扫描器报出的表面漏洞。一个中危漏洞深入利用后，可能串联成严重的安全事件。
注重业务逻辑漏洞：这是自动化工具无法发现的。例如：
详细、实时地记录
记录每一步操作：包括使用的工具、Payload、请求和响应数据包、时间戳。
截图/录屏：这是最直观的证据。
清晰的记录不仅是为了写报告，更是为了在出现问题时能快速回溯和定位，也是证明测试行为合规的关键。
保持沟通
定期向项目负责人汇报进展，特别是发现严重漏洞时，应立即口头通知，以便对方能及时采取临时防护措施。
三、 测试后：报告与跟进阶段
这个阶段决定了渗透测试的最终价值——能否真正帮助提升安全性。
编写高质量的报告
执行摘要：给管理层看，用非技术语言描述整体风险状况、发现的严重问题及其业务影响。
详细技术报告：给开发/运维团队看，包含每个漏洞的详细描述、复现步骤（Step-by-Step）、请求/响应截图、漏洞定位（URL、参数）、风险等级（CVSS评分）。
修复建议：提供具体、可操作的修复方案，而不仅仅是“存在SQL注入”这样的结论。最好能提供代码示例或配置修改建议。
报告是渗透测试的最终产品，必须清晰、准确、可操作。
结构应包括：
风险等级评定要客观
结合漏洞的利用难度和业务影响来综合评定风险等级（高危、中危、低危）。
一个容易被利用且能直接获取核心数据的漏洞，无疑是高危；一个难以利用但影响很大的漏洞，可能是中危。
成果汇报与评审
向技术团队和管理层分别进行汇报，确保所有人都理解风险所在。
与开发团队一起评审漏洞，解答他们关于漏洞原理和修复方案的疑问。
跟进与复测
渗透测试的终点不是提交报告。必须建立跟进机制。
在开发团队声称修复所有漏洞后，必须进行复测，以验证漏洞是否被彻底、正确地修复，且没有引入新的问题。
关闭漏洞的生命周期，形成安全闭环。
