去年某电商平台被拖库，应用起因是漏洞一个上传接口没校验文件类型。攻击者传了个JSP木马，从错直接拿到服务器权限。误类事后复盘，型上漏洞报告里写得清清楚楚：文件上传类型校验缺失。主包这类问题每天都在发生，应用但很多人对漏洞的漏洞分类其实模糊得很。
从错误类型切进去看，从错应用漏洞大致能分成几块。误类这个分法不是型上教科书上的标准答案，是主包我自己排查和读报告时慢慢梳理出来的，比按OWASP Top 10背更顺手。应用
输入验证类：最古老也最致命
SQL注入、漏洞XSS、从错命令注入、XXE，全都属于这一类。核心问题就一个——程序信了用户输入。
我见过一个后台查询功能，前端做了长度限制，后端直接拼SQL。安全测试时输入一个单引号，数据库报错信息直接弹到页面上，库名、表名一览无余。开发者的说法是“前端已经限制了”，可Burp一抓包改掉参数，前端那层限制形同虚设。
XSS同理。某论坛的搜索框把关键词原样输出到HTML里，没做实体编码。输入<img src=x onerror=alert(1)>，弹窗就出来了。存储型的话更麻烦，每个访问该页面的用户都会中招。
这类漏洞的修复思路不复杂：白名单校验、参数化查询、输出编码。难的是开发者愿不愿意在每个入口都老老实实做一遍。
逻辑缺陷类：扫描器扫不出来的那种
这类漏洞没有固定payload，AWVS和Burp的主动扫描基本无能为力。
举个真实例子。某优惠券系统，用户领取后点击使用，请求里带了coupon_id和user_id。测试时把user_id改成别人的，优惠券照样核销成功——越权。再进一步，把coupon_id遍历一遍，能把所有未使用的券全部领走。代码逻辑上没有任何“注入”特征，但业务被薅穿了。
还有密码找回。某站点重置密码的token是六位纯数字，且没有次数限制。写个脚本跑一小时，直接重置任意用户密码。这种问题扫描器报告里永远不会出现，只能靠人工去推演业务流程。
身份认证与会话管理类
弱口令、session固定、JWT密钥硬编码、OAuth回调地址未校验——都归这里。
印象比较深的是一个移动端API，登录成功后返回的token里把用户角色写在了payload里，签名用的密钥是secret。改一下role字段，重新签个token，普通用户秒变管理员。这种设计上的偷懒，比代码bug更难发现，因为功能测试阶段一切正常。
配置与依赖类：被忽视的重灾区
Spring Boot Actuator端点未授权访问、Nginx目录遍历、Redis未授权、Log4j2远程执行——这些严格说不算“应用代码”的漏洞，但攻击面完全一样。
我扫过一个内网系统，/actuator/env直接能访问，数据库密码明文躺在响应里。开发说“内网没关系”，可一旦有一台机器被突破，横向移动的成本几乎为零。
依赖漏洞更隐蔽。项目里引了某个老版本的Fastjson，谁也没注意。直到安全扫描报了反序列化RCE，才回头去翻pom.xml。供应链上的问题，靠人眼review代码根本防不住。
资源管理类
内存泄漏、连接池耗尽、无限递归导致的拒绝服务。这类漏洞在功能测试时往往表现为“偶尔卡一下”，很容易被忽略。但攻击者可以构造特定请求，让服务在几秒内不可用。某次压测时发现，一个正则表达式回溯严重，输入特定字符串直接吃满CPU。代码本身没有安全漏洞，但可用性被打穿了。
漏洞分类的意义不在于贴标签，而在于定位修复方向。输入验证问题去改校验逻辑，逻辑缺陷得重新梳理业务流程，配置问题查部署清单。分类错了，修复方案也跟着错。
实际工作中，一个漏洞往往横跨多个类型。文件上传没校验类型是输入验证问题，上传后的文件能被解析执行是配置问题，上传接口没有权限控制是逻辑缺陷。分清楚这些，比背一百个CVE编号有用。