渗透测试， 每一项发现都经人工验证。
由人来做的渗透测试：手工利用，每一项发现在写入报告前都先复现一遍。目标不是罗列哪些地方看起来有问题，而是证明攻击者用您今天暴露出去的东西究竟能做到什么。
渗透测试能回答、而扫描器回答不了的问题
自动化工具指出哪里看起来有问题。渗透测试则证明什么是真的可以被利用的，以及这份访问权能延伸多远。差别体现在串联上：一个单独看只算低危的授权缺陷，一旦能通向那个用户本不该接触的数据，就变成了高危。没有哪种工具能自己拼出这条路径——而真正改变修复优先级的，是路径，不是标签。
- 每一项发现都先人工复现再写进报告：工具的原始输出不是交付物。
- 风险按它对您业务的影响来描述，而不只是公开数据库里的一个通用评分。
- 误报不会送到您面前——凡是我们复现不出来的，都不进文档。
- 利用路径逐步记录在案，方便您的团队自己重跑一遍、确认修复是否到位。
服务包含内容
以下范围是常规项目的默认配置。在范围沟通阶段均可调整，不另收费。
- 身份认证、会话处理与密码找回
- 按对象划分的横向与纵向授权
- 查询、命令与模板中的注入
- 业务逻辑与可被绕过的流程
- 文件上传、处理与对外提供
- 响应头、Cookie 与 CORS 配置
- 资源枚举与可预测的标识符
- 跨账号、跨租户的访问控制
- 结构校验与异常类型的处理
- 频率、成本与自动化滥用的限制
- 服务间认证与密钥轮换
- 响应中返回过多数据
- 对外暴露的边界与被遗忘的服务
- 已停止支持的版本与待打的补丁
- 环境之间与网络之间的隔离
- 从边界可直接触达的内部服务
- TLS 配置与流量终结
- 从初始立足点开始的横向移动
- 身份提供方与联合登录流程
- 第二因素：覆盖范围、绕过方式与找回途径
- 继承而来的权限与权限累积
- 服务账号与硬编码在代码里的凭据
- 多设备会话与吊销机制
- 新用户注册与开通流程
- Android 与 iOS 应用，含本地存储
- 应用与 API 的通信及证书绑定
- 防篡改保护，以及在已被控制设备上的行为
- 企业无线网、访客网络，以及两者之间的隔离
- 本地基础设施，以及它能触达的云端资源
- 自助终端、收银终端与共用设备
- 注入：SQL、NoSQL、LDAP、命令与模板
- 认证、授权、IDOR 与权限提升
- SSRF、XXE 与不安全的反序列化
- 业务逻辑与支付流程缺陷
- 可证明影响的 XSS、CSRF 与点击劫持
- 弱加密、可预测的令牌与脆弱的 JWT
实施方式
按范围调整黑盒
我们从零信息开始，与外部攻击者处在同一位置。这衡量的是您的攻击面对一个陌生人交出了什么，并且常常会翻出没人知道已经暴露在外的资产。
灰盒
我们拿到账号与架构概览。在同样的时间窗口内覆盖面最广，因为精力用在利用而非侦察上——授权类缺陷也正是在这种方式下浮出水面。
白盒
可查阅代码、配置与文档。能触及从外部很少显现的路径，例如竞态条件、异常处理，以及埋在多层之下的敏感逻辑。
什么时候做渗透测试最划算
这不是一年一次的走过场。有些时刻，测试的回报明显高于成本：要么攻击面变了，要么外部很快就要来问了。
重构、更换身份提供方、迁移环境，都会挪动那些没人再回头核对的前提假设。在变更前测试，比事后带着真实流量去发现要便宜得多。
企业合同、安全问卷与采购流程，往往都要求一份独立测试。报告能客观地回应这些要求，而不必依赖自评。
新团队、新服务、新集成。快速增长会造出没人完整梳理过的攻击面，以及当初作为临时措施放开、后来再没收回的权限。
老旧的内部系统、管理后台与陈年集成，常年被排除在所有测试范围之外——恰恰因为大家觉得它们“太内部了，不用担心”。
我们如何推进
[流程]范围与交战规则
在发出第一个数据包之前，我们把范围内、范围外、允许的时间窗口，以及一旦偏离计划该联系谁，全部写成文字。同时约定高危发现的中止标准，让严重问题当天就送到您手里，而不是等最终报告。
侦察与测绘
我们还原真实的攻击面：域名、子域名、暴露的服务、所用技术、入口点，以及关于该环境已经公开的一切。资产清单里缺失的东西，通常就在这个阶段现身——一个可访问的预发布环境、一个被遗忘的后台、一个为测试搭起来却一直没关的服务。
扫描与分诊
自动化只属于这一步，也仅限这一步：它负责覆盖量，并给出候选项。每条结果都要经人工分诊，因为工具标出来的东西，大多在有人试图复现时就站不住脚。挺过分诊的，才成为可供利用的假设。
手工利用
这一步把测试和扫描区分开来。我们串联缺陷、试探业务逻辑、尝试提升权限，并设法触及本该受保护的数据——始终在约定规则之内，且不影响生产环境的可用性。
后渗透与可达范围
找到门不是重点，重点是门通向哪里。我们衡量一个初始立足点能延伸多远、从这里能读到什么、改动什么、能否留存，以及是否能顺势触达另一套系统。正是这项衡量，把技术评分变成业务风险。
报告与复测
报告包含可复现的路径、影响与建议修法，管理层读法与技术细节分开呈现。修复之后，我们对已处理项进行复测，并记录哪些已经关闭——因为一项漏洞只有在有人确认后才算真的修好。
工作背后的公开依据
我们遵循公开且被广泛认可的方法论。这样一来，不同供应商之间的范围可以对比，您的审计方也能自行核对覆盖了什么，而不必只听我们一面之词。
- OWASP WSTG
- OWASP Web 安全测试指南按类别组织覆盖范围——认证、会话、授权、校验、业务逻辑——为说明“验证了什么”提供了清晰依据。
- OWASP API Security
- API 风险清单覆盖传统 Web 测试处理不好的部分：对象级授权、返回数据过多，以及无节制的资源消耗。
- PTES
- 渗透测试执行标准描述了从前期沟通到报告的各个阶段，也是上文流程的主干。
- MITRE ATT&CK
- 这份攻击者战术与技术目录，为我们执行过的动作提供统一命名，方便贵方防守团队把每一步与检测“看到了什么、漏掉了什么”逐一对照。
- NIST SP 800-115
- NIST 的安全测试技术指南界定了计划、执行与测试后的工作，也是合同要求中最常被引用的参考。
- CVSS
- 评分把技术严重程度标准化，但它只是输入项之一：优先级仍依据它在您环境中的实际影响，并以平实文字写在分数旁边。
交付物
双视角 · 保密协议管理层摘要
写给掌握预算与优先级的人的一份短文：测了什么、哪些构成真实风险、哪些需要拍板。不用术语，放到董事会上也站得住。
附完整复现步骤的发现
每一项都带有逐步路径，含请求、响应与证据。开发人员无需追问即可复现，也不必依赖当初执行测试的人。
影响与优先级评估
技术严重程度与业务影响分开列出，因为两者并不总是一致。建议的处理顺序把修复投入也算进去，避免团队一上来就啃最贵、最不紧急的那一项。
针对性的修复建议
结合您的代码与架构给出建议，而不是从文档里抄来的通用段落。若存在多条修法，报告会说明每条的取舍。
与您的监控做对照
按技术手法归类的执行记录摘要，供您的检测团队与日志、告警实际捕获的内容作比对。它揭示的问题往往不亚于漏洞清单本身。
复测与结项函
修复后我们重新查看已处理项，并记录最终状态。这份文件可提供给需要闭环证据的客户、合作方与审计机构。
常见问题
默认不测可用性。拒绝服务以及任何高风险操作都排除在范围之外，除非您明确要求并约定时间窗口。若某项测试可能影响生产，则移到等价环境执行，或在约定窗口内进行，全程保持直连沟通。
明确的范围、覆盖每种用户角色的测试账号，以及一位随时可联系的技术对接人。如果边界防护可能拦下测试，我们会共同决定它是列入范围还是加白——测防护和测应用是两个不同的目标。
扫描把发现的内容与已知漏洞库比对，然后给你一份清单。渗透测试会尝试真正利用、串联缺陷，并衡量访问权能延伸多远。扫描便宜，适合持续监控；人工测试回答清单答不了的问题——这一条在您的环境里究竟能不能被利用。
可以。管理层摘要面向非技术读者撰写，可直接提供给客户、合作方或审计机构。技术细节单列一章，而复测后出具的结项函，通常就是采购流程中被接受的那份证明。
取决于风险。若存在与生产高度一致的预发布环境，我们优先用它，因为可以测得更放开。若只有生产环境——这也是常见情况——我们会限制破坏性操作、约定时间窗口，并全程保持沟通渠道畅通。
按开始前约定的中止标准执行：高危发现立即通报，附上您采取行动所需的最少信息，不等最终报告。情况需要时，执行会暂停，直到风险被控制住。
取决于您变化的速度。持续发布的应用每周都在改变攻击面，一年一测看到的是一套已经不存在的系统。常见做法是：主范围定期测，再在每次结构性变更时做一次针对性测试——新增集成、更换身份提供方、上线新环境。