内容摘要：去年给一家做跨境电商的客户做渗透，前端翻了个遍没找到入口，最后是在一个没人管的旧版API接口上撕开的口子——那个接口连文档都没有，开发早离职了，但服务器还活着。这事让我意识到，漏洞分类不能只按OWAS

去年给一家做跨境电商的渗透客户做渗透，前端翻了个遍没找到入口，测试最后是漏洞在一个没人管的旧版API接口上撕开的口子——那个接口连文档都没有，开发早离职了，分类但服务器还活着。渗透这事让我意识到，测试漏洞分类不能只按OWASP那套来，漏洞得看它在真实攻防里扮演什么角色。分类

按利用位置分，渗透最粗暴的测试就是边界漏洞和内网漏洞。边界漏洞是漏洞能从公网直接打的，比如未授权的分类API、弱口令的渗透管理后台、暴露的测试数据库端口。去年某物流公司被拖库，漏洞起因就是Redis没设密码还开着公网，攻击者写了个定时任务直接反弹shell。这种漏洞的特征是“不用动脑子就能发现”，Shodan扫一遍能捞出一堆。内网漏洞则是拿到一个低权限据点后才能碰的，比如域环境里的Kerberoasting、内网服务的未授权访问。打内网漏洞更像拼图，你得先有立足点，再靠信息收集一点点摸清拓扑。

按成因分，我习惯分成三类：代码写错的、配置搞砸的、设计缺心眼的。代码写错的典型是SQL注入和XSS，本质是没对用户输入做处理。这类漏洞现在纯手工挖的少了，大多是靠扫描器扫出来再手工验证。配置搞砸的更有意思——S3存储桶权限设成public、Nginx配了autoindex、Tomcat开着manager弱口令。这类漏洞跟开发没关系，纯粹是运维或DevOps的锅。设计缺心眼的就麻烦了，比如密码重置逻辑用手机号后四位验证、JWT密钥硬编码在客户端、越权只靠前端隐藏按钮。这种漏洞扫描器基本扫不出来，得靠人理解业务逻辑后手动构造请求。

还有个维度是按利用效果分：直接拿权限的、偷数据的、当跳板的。直接拿权限的比如RCE、文件上传getshell，打进去就是最高权限。偷数据的比如SQL注入、未授权API返回敏感信息，攻击者不一定要控制服务器，把数据拖走就行。当跳板的比如SSRF、CRLF注入，本身危害不大，但能用来打内网或劫持会话。我遇到过最阴间的组合是SSRF打云元数据服务，直接拿到临时凭证接管整个AWS账户——单个漏洞评级不高，串起来就是灾难。

说个具体案例。某次测一个SaaS平台，登录口有验证码，爆破不了。但注册接口没做频率限制，我写了个脚本批量注册，用注册时的手机号枚举功能把管理员手机号猜出来了。然后密码重置逻辑是“发送验证码到手机”，但验证码是6位数字且没锁定。我用注册的账号先摸清验证码生成规律——居然是时间戳后六位。直接构造请求重置了管理员密码。这条链上每个点单独看都不算高危：注册无限制、手机号可枚举、验证码可预测。但组合起来就是完整的账户接管。所以漏洞分类如果只看单个漏洞的CVSS评分，会漏掉这种“逻辑链漏洞”。

实际项目中，我花在分类上的时间很少。更多是边测边标记：这个点能干什么、需要什么前提、能延伸到哪。分类是给报告读者看的，不是给攻击者用的。攻击者眼里只有“能走通的路”和“走不通的路”，漏洞标签只是事后贴上去的便利贴。