1. 项目概述为什么说“范围界定”是渗透测试成败的第一道防线干了这么多年渗透测试我见过太多项目从一开始就“跑偏”了。客户说“帮我测一下系统安不安全。” 测试团队一头扎进去一周后交出一份报告客户一看“你怎么把我生产数据库给搞挂了” 或者反过来测试团队小心翼翼最后报告里全是些不痛不痒的低危漏洞客户觉得钱白花了。问题的根源十有八九出在“范围界定”这个最容易被轻视的环节上。渗透测试范围界定说白了就是在动手之前和客户一起把“测什么、不测什么、怎么测、测到什么程度”这些规矩白纸黑字地定下来。这绝不是走个形式、签个授权书那么简单。它是一份作战地图也是一份责任划分协议。一份清晰、严谨的范围界定文档能帮你避开法律雷区防止业务中断把有限的测试资源精准地用在刀刃上最终产出一份真正对客户有价值、能落地的安全报告。今天我就结合自己踩过的坑和总结的经验跟你聊聊如何从零开始制定一份靠谱的渗透测试范围界定方案把实战技巧揉碎了讲给你听。2. 范围界定的核心四步法从混沌到清晰很多人觉得范围界定就是列个IP地址清单其实远不止于此。它是一个系统性的沟通、分析和决策过程。我把它总结为四个环环相扣的核心步骤缺一不可。2.1 第一步明确测试目标与成功标准——搞清楚“为什么测”这是所有工作的起点也是最容易产生误解的地方。客户说“做个安全测试”背后的真实诉求可能千差万别。你必须和客户深入沟通明确以下几点驱动因素是什么是合规性要求比如等保测评、PCI-DSS支付卡行业标准是应对某个具体的威胁情报还是公司内部流程的例行安全检查驱动因素直接决定了测试的侧重点和报告格式。核心业务资产是什么客户最宝贝的是什么是存放用户交易记录的数据库是支撑核心算法的API服务器还是公司官网的品牌形象你需要和客户一起基于业务影响和资产价值给目标系统排个优先级。通常我会建议使用“业务关键性”和“数据敏感性”两个维度来绘制一个简单的矩阵直观地识别出高价值目标。成功的标准是什么测试做到什么程度算成功是发现至少X个高危漏洞是验证某个特定攻击路径是否可行还是出具一份能满足某审计方要求的合规报告把这个标准量化、具体化后期评估测试效果时才有据可依。实操心得在这个阶段我强烈建议使用“用户故事”或“攻击者画像”的方法来辅助沟通。比如和客户一起描述“一个具备中等技能的外部攻击者是否可能窃取普通用户的账户信息” 这种场景化的描述比单纯的技术术语更能帮助业务方理解测试的价值。2.2 第二步划定测试边界——说清楚“测哪里不测哪里”这是范围界定文档里最核心、最需要细化的部分。边界划得模糊就是给自己挖坑。这里要严格区分In-Scope包含项和Out-of-Scope排除项。In-Scope必须清晰、无歧义地列出目标标识具体的域名如app.example.com、IP地址段如192.168.1.100-192.168.1.150、公网IP、甚至移动应用的App ID。避免使用“所有相关系统”、“子公司网络”这种模糊表述。应用/服务范围是针对某个Web应用的前后端还是包含对应的API接口api.example.com/v1/*或者是整个办公网的网络设备测试类型是黑盒测试零知识灰盒测试提供低权限账号或部分架构图还是白盒测试提供源代码不同类型的测试所需时间和深度天差地别。授权凭证如果进行灰盒测试客户需要提供哪些测试账号每种账号的权限等级是什么例如普通用户、VIP用户、后台管理员。测试时间窗口明确测试的起止日期。更重要的是约定每天可以进行测试的时段例如工作日9:00-18:00以及必须避开的“静默期”如电商平台的大促日、金融系统的月结日。Out-of-Scope必须明确排除并解释原因禁止触碰的系统例如核心生产数据库服务器IP: 10.0.1.10、负载均衡器管理口、第三方供应商的系统如支付网关、短信平台。这些系统一旦出问题影响可能是灾难性的。禁止使用的攻击手法例如明确禁止拒绝服务DoS/DDoS攻击、禁止对客户员工进行实质性的社会工程学攻击如钓鱼邮件、禁止物理入侵测试如尾随进入机房——除非这些已作为特殊测试项被单独授权并制定了周密计划。敏感数据处理明确声明测试过程中如意外获取到真实用户个人信息PII、财务数据等应立即停止相关测试并按照既定流程上报且不得存储、泄露。其他限制例如不得使用某些攻击性过强的自动化扫描工具或禁止对某个老旧且已知脆弱的系统进行深度测试以防其直接崩溃。2.3 第三步制定测试规则与限制——约定好“怎么玩”规则是测试过程中的行为准则确保测试在可控、合规的轨道上进行。沟通与上报机制日常沟通每日或每周进度同步的窗口和形式邮件/会议。紧急事件上报发现可能导致业务立即中断或数据泄露的严重漏洞如RCE、数据库未授权访问时应立即停止测试并通过预先约定的紧急联系人最好提供2个不同方式的联系人第一时间通知。这个流程必须写进文档。技术方法限制是否允许使用漏洞扫描器如果允许是哪种扫描强度全扫、快速扫描、仅爬虫是否允许进行暴力破解如果允许速率限制是多少如每秒5次请求。是否允许测试WAFWeb应用防火墙的绕过这需要特别谨慎。变更管理流程测试过程中如果客户想临时增加一个目标或者测试团队发现一个关联系统也存在风险想纳入测试该怎么办必须有一个正式的“范围变更”流程通常需要客户方项目经理的书面邮件确认并评估对项目时间和成本的影响。2.4 第四步形成书面文档并确认——落下“白纸黑字”前面所有讨论的产出必须凝结成一份正式的《渗透测试范围界定文档》或《工作说明书SOW》。这份文档需要双方项目经理或负责人签字确认。它不仅是授权书更是解决未来潜在争议的依据。一份完整的范围界定文档应包含项目概述背景、目标、成功标准。范围明细详细的In-Scope和Out-of-Scope清单。测试方法允许的技术、工具、测试类型。时间计划项目各阶段时间表。交付物最终报告的形式、内容、交付时间。双方责任客户需要提供的资源如联系人、测试账号、网络访问权限测试团队的责任。法律与保密条款授权声明、保密协议NDA、责任限制条款。3. 实战技巧如何应对范围界定中的典型挑战理论说完了我们来点干的。在实际项目中范围界定从来不是一帆风顺的。下面是我总结的几个最常见挑战及应对技巧。3.1 挑战一客户说不清自己有什么资产很多中小型客户尤其是业务部门发起测试时可能连自己有多少台服务器、多少个对外服务都说不全。应对技巧引导式提问从业务角度出发。“咱们公司最核心的业务是什么这个业务是靠哪个网站或APP支撑的它的网址/名字是什么” 先抓住核心。利用已有信息申请查看现有的网络拓扑图哪怕不是最新的、域名备案列表、云服务商的控制台概览。辅助以温和的侦察在获得对主域名测试授权后可以进行有限的公开信息收集OSINT如子域名枚举使用amass,subfinder等工具、端口扫描仅针对授权域名解析出的IP。但切记这些辅助侦察活动本身也必须写入范围界定明确其边界你可以这样写“为明确测试边界测试方将对example.com进行被动的子域名发现和公开端口探测此活动不涉及任何主动的漏洞扫描或利用尝试。”3.2 挑战二范围“蔓延”Scope Creep测试到一半客户突然说“哎顺便帮我们也看看新上线的那个小程序吧”或者“隔壁那个系统好像也有点关联一起测了吧”。这是项目管理中的大忌。应对技巧事前明确变更流程在文档中专门设立“变更管理”章节写明任何范围变更都需要书面申请、评估影响时间、成本、风险、并由双方负责人批准。坚守原则灵活处理对于小的、关联性强的增项如果评估后对整体计划影响很小可以记录在案后执行并在最终报告中说明。对于大的增项坚决启动变更流程该加钱加时间就明确提出来。你的专业和严谨最终会赢得客户的尊重。3.3 挑战三在“测试深度”和“覆盖广度”间权衡资源时间、人力总是有限的。是盯着一个系统往死里挖深度还是把十个系统都快速过一遍广度应对技巧风险优先级导向回到第一步根据资产价值排序。对核心、高价值的系统进行深度测试如手动代码审计、复杂的业务逻辑漏洞挖掘对边缘、低价值的系统进行广度覆盖如自动化扫描加人工结果复核。采用分阶段测试与客户协商将测试分为多个阶段。第一阶段广度扫描快速发现所有系统的“表面”漏洞。第二阶段针对第一阶段发现的高风险系统进行深度测试。这样既能快速给出风险全景又能深入要害。3.4 挑战四处理第三方和上下游系统客户的系统往往调用第三方API或者被集成到更大的生态中。这些系统通常被划为Out-of-Scope但又是真实的攻击面。应对技巧明确区分责任边界在文档中清晰写明“对于api.payment.com第三方支付接口的测试不在本次范围内其安全性应由服务提供商保证。”提供风险提示在测试中如果发现自身系统在与第三方交互时存在不安全的设计如API密钥硬编码、传输未加密虽然不能测试第三方本身但可以在报告中明确指出这种“集成风险”并建议客户向服务商索取安全证明或推动安全整改。4. 核心环节实现撰写一份滴水不漏的范围界定文档光说不练假把式。下面我以一个虚构的“智联招聘网企业版Web应用渗透测试”项目为例展示一份范围界定文档的核心部分应该怎么写。你可以把它当作一个模板来参考。# 渗透测试项目范围界定文档 **项目编号:** PT-2023-001 **客户名称:** 智联招聘网 **测试方:** [你的安全公司] **文档版本:** V1.2 **最后更新:** 2023-10-27 ## 1. 项目概述 1.1 **测试目标:** 评估“智联招聘企业版”Web应用hr.zhaopin.com及其相关API的安全性识别可能被外部攻击者利用的漏洞提升整体安全水位满足年度安全审计要求。 1.2 **成功标准:** - 发现并验证至少3个中危及以上等级的安全漏洞。 - 完成对核心业务流企业注册、职位发布、简历管理、在线沟通的安全测试。 - 提供具有明确修复建议的详细测试报告。 ## 2. 测试范围 2.1 **包含项 (In-Scope):** - **主要目标:** hr.zhaopin.com 域名下所有子路径。 - **API接口:** api.zhaopin.com/hr/v1/* (仅限与hr.zhaopin.com前端交互的接口)。 - **IP地址:** 上述域名解析出的所有公网IP地址预计属于CIDR范围: 203.0.113.0/24。 - **测试账号:** 客户将提供2个企业账号不同权限等级用于灰盒测试。 - **测试类型:** 黑盒测试对外服务 灰盒测试使用提供账号。 - **测试时间:** 2023年11月1日 09:00 - 2023年11月10日 18:00仅限工作日。 2.2 **排除项 (Out-of-Scope):** - **系统:** admin.zhaopin.com后台管理系统、payment.zhaopin.com支付子系统、任何数据库服务器的直接访问如10.内部.xx.xx。 - **第三方服务:** 腾讯云验证码、阿里云OSS存储服务、短信网关服务商。 - **禁止的测试方法:** - 任何形式的拒绝服务DoS/DDoS攻击或压力测试。 - 对智联招聘员工、用户或任何个人的社会工程学攻击如钓鱼。 - 物理安全测试。 - 使用已知攻击性极强、可能造成服务不稳定的自动化漏洞利用工具如SQLMap的--level 5以上参数进行盲注。 - **数据:** 严禁下载、存储、泄露测试过程中接触到的任何真实用户简历数据。一旦意外获取立即停止相关操作并上报。 ## 3. 测试规则与限制 3.1 **通信协议:** - 所有测试流量必须通过客户指定的监控节点IP: 198.51.100.1发出以便客户安全团队进行监控和溯源。 3.2 **攻击强度限制:** - 暴力破解尝试每秒不超过3次请求。 - 目录/文件枚举使用常见字典避免无限遍历。 3.3 **漏洞上报流程:** - **中低危漏洞:** 每日汇总通过加密邮件发送给客户接口人。 - **高危/严重漏洞:** 立即暂停相关测试模块通过电话主联系人张安全138-xxxx-xxxx备用联系人李运维139-xxxx-xxxx和加密即时通讯工具双重通知。 3.4 **范围变更:** 任何对上述范围的修改需经双方项目经理邮件书面确认并可能引发项目周期与费用的调整。 ## 4. 交付物 - 一份详细的渗透测试报告Word/PDF格式包含执行摘要、测试详情、漏洞描述含复现步骤、风险等级、影响证明、修复建议。 - 一次线上的报告解读会议。 ## 5. 授权 双方签署本文件即表示客户授权测试方在上述约定的时间、范围和规则内对指定目标进行安全渗透测试。测试方承诺将遵循专业道德最小化对业务的影响。 **客户授权签字:** __________ 日期: __________ **测试方授权签字:** __________ 日期: __________5. 常见问题与排查技巧实录即使文档写得再完美实战中还是会遇到各种幺蛾子。下面是我记录的一些典型问题及解决方法希望能帮你提前避坑。5.1 问题测试中触发了客户的WAF或IPSIP被封锁。排查与解决预防优于解决在范围界定阶段就应询问客户是否有WAF/IPS并申请将测试团队的源IP地址或整个IP段加入到监控系统的白名单或“观察模式”仅记录不拦截。立即沟通一旦发现被封锁立即通过紧急联系人通知客户安全团队提供被封锁的IP和大致时间请求解封。调整策略如果无法完全避免触发则需调整测试手法。例如降低扫描速率在请求中添加更常见的User-Agent避免短时间内对同一路径发起大量畸形请求。5.2 问题客户提供的测试账号权限不足或无法登录。排查与解决测试前验证在测试正式开始前1-2天要求客户提供测试账号并进行登录验证确保账号状态、权限正常。准备备用方案在范围界定中约定如果提供的账号出现问题客户需在X小时内提供替代账号否则因此延误的时间不计入测试周期。记录影响如果因账号问题导致部分测试无法进行需在最终报告中明确说明并指出因此可能未被覆盖的风险面。5.3 问题发现一个严重漏洞其利用会影响一个Out-of-Scope的系统。案例你在测试Web应用In-Scope时通过一个SQL注入点可以读取到数据库连接配置文件里面明文写着核心生产数据库Out-of-Scope的IP和密码。处理技巧立即停止立即停止对该漏洞链的进一步利用绝对不要去连接那个生产数据库。紧急上报按照紧急流程上报。在报告中你可以这样描述“在hr.zhaopin.com上发现一个SQL注入漏洞高危。概念性证明PoC显示利用此漏洞可获取到内部数据库连接凭据。由于该内部数据库属于Out-of-Scope范围我们未进行进一步验证。但此漏洞直接导致核心数据库面临极大风险建议立即修复。”原则证明漏洞存在和影响即可绝不跨越约定的红线。你的专业操守比多证明一个点更重要。5.4 问题测试时间窗口与业务高峰期冲突。处理技巧在制定计划时就应充分了解客户的业务周期避开“双十一”、“月末结算”等关键时段。如果测试必须在业务时段进行则应在规则中明确“只读性测试”或“非侵入式测试”原则并约定更严格的监控和更频繁的沟通。考虑采用“时间窗口测试法”比如只在凌晨2点到5点进行可能造成高负载的扫描或测试。范围界定不是渗透测试的“前菜”而是决定整场“安全盛宴”口味和成败的“食谱”。花在沟通、梳理和文档上的每一分钟都会在后续的测试、报告和问题跟进中十倍地回报你。它建立的是信任规避的是风险保障的是价值。下次启动项目前别再急着打开扫描器先坐下来和你的客户一起把这张“作战地图”画清楚、画细致。你会发现之后的每一步都走得更加踏实、有力。