弱点基础知识全解析：从CVE/CWE/CVSS到代码审计实战

1. 先从最基础的问题聊起弱点到底是什么做安全这行不管是刚入门的实习生还是干了七八年的老油条都会反复碰到一个词弱点。不管你叫它漏洞、脆弱性、还是英文的Vulnerability本质上说的都是同一件事——信息系统里那些能被利用来干坏事的设计缺陷或实现缺陷。我在刚开始接触这块内容的时候也犯过迷糊总觉得“弱点”和“漏洞”是两个概念。后来被前辈点醒才明白这俩在日常语境里基本可以混用只是在专业场景下会有细微区别。比如在CVSS通用漏洞评分系统里官方叫法是Vulnerability中文社区翻译成“漏洞”和“弱点”的都有。本篇文章作为这个系列的第五篇我打算把最容易被大家忽略、但又特别关键的基础框架讲透包括弱点靠什么规范来定义、分数怎么算、生命周期长什么样、以及平时做代码审计时最该盯住哪几类问题。为什么这个内容重要因为我发现一个现象很多刚入行的朋友热衷于刷CVE编号、追热点漏洞结果真到了自己写代码或者做安全测试的时候连一个最普通的越权问题都说不清楚。这就像你天天看F1比赛却连自己车子的刹车原理都不懂——看热闹没问题真上场就露馅。所以这篇文章不追踪任何具体漏洞就老老实实把“弱点”这件事的地基给你打牢。适合这几类人看刚转行做安全的新人、写代码但没系统学过安全知识的开发人员、以及准备考取安全相关认证、需要把基础知识梳理一遍的朋友。咱们不整虚的直接进入正题。2. 弱点的“身份证”CVE、CWE、CVSS到底怎么配合想搞清楚弱点你脑子里得先装下三套体系。就好比你去医院看病CVE是病历号CWE是病理分类CVSS是病情严重程度评分。三者的分工完全不同但很多人总是搞混。2.1 CVE编号每个漏洞的唯一标识CVE全称是Common Vulnerabilities and Exposures由MITRE组织维护。每一个被公开确认的漏洞都会拿到一个CVE编号格式一般是“CVE-年份-序号”比如CVE-2024-12345。这个编号是全世界通用的安全厂商、漏洞库、扫描器全都拿它来指代同一个漏洞。有一点你得注意CVE编号本身不包含技术细节。它就像你的身份证号只是用来标识“你是你”。至于这个漏洞到底是什么原因导致的、影响范围多大、怎么修复这些信息都在CVE描述里需要去看官方公告或者各大漏洞库的分析。我见过不少新手拿到一个CVE编号跑过来问我“这个漏洞怎么利用”结果我一看那是个仅存在于特定硬件固件里的问题跟他用的系统八竿子打不着。所以第一节课就要记住CVE只是入口不是答案。2.2 CWE分类弱点的“病种诊断”CWECommon Weakness Enumeration同样是MITRE维护的它解决的问题是“这个弱点属于什么类型”。打个比方CVE是给每个具体的病人发病历号CWE则是给病分类——这是流感那是骨折这是食物中毒。CWE对弱点有非常详细的层级分类比如CWE-89是SQL注入CWE-79是跨站脚本XSSCWE-352是跨站请求伪造CSRFCWE-200是信息泄露。每一个大类下面还有子类比如把注入问题细分出命令注入、LDAP注入、XPath注入等等。做代码审计的时候CWE的价值特别大。因为你发现一个问题后需要判断它属于哪种弱点类型才能决定后续按什么思路去验证、怎么设计修复方案。比如看到用户输入拼进了SQL语句归类到CWE-89第一反应就是用参数化查询来修看到输出直接渲染到页面上归类到CWE-79那修复思路就要换成输出编码。2.3 CVSS评分弱点的“病情评估”CVSSCommon Vulnerability Scoring System现在用的是3.1版本。它通过一套复杂的计算公式从攻击向量、攻击复杂度、所需权限、用户交互、影响范围、机密性影响、完整性影响、可用性影响这八个维度综合打分最终得出一个0到10之间的分数。8.0到10.0是严重等级4.0到7.9是高危0.1到3.9是低危0分是没有风险。但我必须提醒你分数只是参考不要盲信。同样一个CVSS 9.8的漏洞如果你的系统根本不对外开放、前置条件满足不了那实际风险就远没有分数表现的那么夸张。反过来一个CVSS只有5.4的越权漏洞如果恰好发生在你的核心业务接口上那它造成的损失可能比某些9.8的还大。所以这里送大家一个我自己的经验公式真实风险 CVSS分数 × 资产价值 × 暴露程度。三者缺一不可只盯着CVSS看那叫刻舟求剑。3. 弱点的完整生命周期从发现到修复一次说清楚理解了上面三个体系后咱们把视角拉高一点看看一条漏洞从“被发现”到“被修复”到底要经历哪些阶段。我把它拆成六个环节你在实际工作中遇到的任何漏洞都逃不出这个框架。3.1 挖掘阶段漏洞是怎么被发现的漏洞的发现渠道有好几条。一是安全研究员主动挖掘分析开源代码、逆向闭源软件、或者对目标系统做渗透测试发现异常提交漏洞报告。二是厂商自己的内部安全团队在开发过程中做代码审计和上线前扫描把问题提前拦下来。三是恶意攻击者利用漏洞发起攻击被打完之后大家才知道原来那里有个洞。这里插一句很多公司只做上线前扫描忽略了上线后的持续监控结果新漏洞爆发的时候根本反应不过来。这条在后面的问题排查章节还会细讲。3.2 上报阶段漏洞信息传给谁发现漏洞之后按规定流程一般要上报给厂商、CNACVE编号授权机构或者专门的漏洞平台。国内常用的平台包括CNVD国家信息安全漏洞共享平台、CNNVD国家信息安全漏洞库国际上则是MITRE、NVD美国国家漏洞数据库这些。上报时要写清楚漏洞类型、影响版本、复现步骤、修复建议方便厂商快速定位问题。我见过一些新手白帽发现漏洞后第一时间发朋友圈炫耀结果厂商还没修复就先被利用了最后惹上官司。这里必须提醒漏洞披露讲究“负责任的披露”原则给厂商留出合理的修复时间再公开这是行业基本规矩。3.3 验证阶段搞清楚这不是误报厂商收到漏洞报告后要复现一下确认问题属实同时评估影响范围。很多漏洞上报后被打回原因就是复现条件不充分、或者问题只存在于特定环境下、或者上报者自己都不确定是不是真的存在风险。所以如果你提交漏洞一定要把复现环境、触发的请求报文、响应信息都整理清楚最好带上截图或者视频。你在验证别人系统的时候严格来说你自己得先把基本功练扎实——这就是本系列一直在铺垫基础知识的原因。3.4 修复阶段开发人员开始动手确认问题后开发人员需要修改代码、发布补丁。这里的难点在于“修得干净”很多修复只是针对上报的那一条路径打了补丁但同样的逻辑在其他模块可能也复现了同类问题一不小心就会漏掉。所以现在逐渐流行用代码扫描工具做全量检测配合人工审计确认防止“修一处漏一片”。3.5 披露阶段漏洞信息公开补丁发布后漏洞信息才会被公开到CVE、NVD、CNVD等平台。在此之前信息一般都处于保密或者有限披露状态。之所以要强调这个流程就是因为同一个漏洞在补丁发布之前和之后被利用的难度和风险完全不一样。3.6 收尾阶段复盘和沉淀这一步很多人不做但我强烈建议你做。修复完成后要把整个漏洞从发现到处置的文档归档分析为什么会出现这类问题在编码规范、测试流程、人员培训等环节做调整防止类似问题再次发生。一个没有复盘的漏洞处置流程是对漏洞的浪费。4. 实战中最高频的五类弱点你至少得认识它们回到代码和系统的真实场景我把实战中遇到最多的弱点类型挑出来给你逐个拆一拆。这一节是基础中的基础没耐心的朋友也建议读完因为后面无论是做渗透测试、代码审计、还是安全开发这几类问题都是绕不开的。4.1 注入类弱点SQL注入是注入类弱点里名气最大的一个。它之所以臭名昭著是因为一旦被利用攻击者可以直接把恶意SQL代码拼进原有的数据库查询语句里轻则越权读取数据重则脱库、删库、拿服务器权限。理解它的根因很简单程序把用户输入当作“代码”去执行了而不是当作“数据”。除了SQL注入还有命令注入、LDAP注入、XPath注入、模板注入等等原理都类似——把不可信数据直接带入到带有“语义”的解析器中。修复手段的核心思路也一致第一使用参数化查询或预编译语句第二严格校验输入内容第三不拼接任何外部数据到可解析的语句中。这三板斧下去绝大多数注入问题就能堵住。4.2 XSS跨站脚本XSS的本质是攻击者的恶意脚本被注入了页面然后在其他用户的浏览器里执行。它分反射型、存储型和DOM型三种。反射型是攻击链接把脚本带进去存储型是把脚本存到服务器上谁访问页面谁中招DOM型是前端JavaScript代码自己处理数据时不安全导致脚本被执行。我实际遇到最多的是存储型XSS因为它危害最大、持久性最强。比如在留言板、用户昵称、文章标题这些用户可控的地方如果服务端不做过滤和转义攻击者写个带脚本的昵称以后每个浏览该用户主页的人都会中招。修复的关键在于输出编码根据输出位置不同HTML上下文编码、JavaScript上下文编码、CSS编码、URL编码要分清楚用成熟的安全编码库来统一处理。4.3 文件上传类弱点只要你的系统有上传头像、上传附件、导入文件这些功能就一定会碰到这一类问题。最经典的利用方式是上传一个WebShell一句话木马然后通过这个后门控制整个服务器。为什么会有这么大的杀伤力因为上传功能本质上把用户的文件写到了服务器的文件系统里如果扩展名校验不严、路径可控、内容校验缺失等于把服务器的大门钥匙递给了攻击者。做好文件上传防护常规做法有这几条白名单限制扩展名、对上传内容做格式检测比如图片必须能正常解析、重命名文件让攻击者猜不到路径、把上传目录和可执行脚本目录隔离、限制目录的执行权限。但我要提醒一点白名单校验一定要做在服务端前端校验只是给普通用户提个醒攻击者绕过前端简直不要太轻松。4.4 越权类弱点越权分水平越权和垂直越权。水平越权是指一个普通用户能操作另一个普通用户的数据比如你登录A账号却通过修改URL里的ID参数看到了B账号的订单。垂直越权是指低权限用户干了高权限才能干的事比如普通用户访问管理员接口把用户删了。越权问题最难搞的地方在于工具扫描很难发现因为它需要理解业务逻辑。两个同样调用了查询订单接口的请求唯一的区别是订单ID归属不同代码层面看不出两样但业务逻辑上就是越权。要修这类问题核心就是“对象级授权检查”每一次数据操作都要校验当前登录用户是否有权限操作这份数据。后端每次查询数据都带上归属条件不要拿前端传的ID盲目查。4.5 不安全反序列化这类弱点在Java、PHP、Python这些支持对象序列化的语言里高发。说白了就是把一段外部传入的序列化数据反序列化成对象时没有校验数据的合法性导致攻击者精心构造的序列化数据被解析后触发了危险操作甚至直接在服务器上执行命令。反序列化问题修复比较麻烦因为很多场景里你没法干脆不用反序列化比如RPC调用、缓存存储。缓解手段包括对反序列化的数据做签名校验、使用白名单限制允许反序列化的类、使用更安全的替代方案比如JSON格式替换Java原生序列化、运行在低权限沙箱里、控制反序列化时能触发的类路径。这条就属于“懂原理才能防得住”的典型光靠工具扫是扫不全的。5. 弱点处置的实操记录我实际处理过的三个场景说了这么多理论来点真实的操作过程。我挑了三个自己实际处理过、很能代表基本功的案例把处置思路和关键步骤完整走一遍。你会发现所谓“基础知识”真到用的时候全是基本功。5.1 场景一一个典型的SQL注入漏洞从确认到修复当年一个内部管理系统上线前的安全测试开发工程师用的是字符串拼接SQL的方式把用户提交的用户名直接拼进去查询。我拿一个单引号测试页面直接报了SQL语法错误确认存在注入点。接着用Burp Suite构造了带注释符的查询语句判断注入类型确认是字符型注入。修复方案很简单把全部SQL语句改成PreparedStatement参数化查询一行代码的改动而已。但真正的坑在后面的复测改完第一条查询语句后我又顺藤摸瓜看了一下这个模块的其他查询发现同类模式还有三处。这就是我前面说的“修一处漏一片”的真实写照。最后我把这个功能模块涉及的所有SQL全量排查了一遍统一重写才算彻底收尾。5.2 场景二存储型XSS的排查和修复另一个项目是论坛系统用户可以在个人简介里写一段文字程序直接把文字渲染在个人主页上。我测试的时候在简介里输入了一个包含script标签的payload然后访问别人打开我的主页弹窗出现了说明脚本被执行。修复处理分两层后端在接收简介时对内容做了白名单过滤不允许任何尖括号出现前端在渲染时也统一走文本插值而不是HTML插值防止“后端漏了前端兜不住”的情况。我特别强调前端输出编码要统一处理是因为很多项目里后端接口是复用的同一个接口可能既给PC端用、又给App用、还开放给第三方如果只依赖后端过滤一旦某个端忘了过滤就白搭了。5.3 场景三越权问题为什么最花时间最后一个场景是我做过的一次订单系统审计。前端点击“查看订单详情”时把订单ID直接传给后端接口后端拿到ID就去查订单表返回数据。我从浏览器里把订单ID改成另一个数字结果返回了别人的订单信息典型的水平越权。这个问题的修复让我印象很深因为它不只是一行代码的事。开发人员最初改成“前端多传一个用户ID后端校验用户ID和订单ID是否匹配”这看起来好像没问题但实际上攻击者连用户ID也能随便改。正确做法是后端根本不信前端传来的用户ID而是从服务端会话里取当前登录用户的身份再校验该用户是否有权访问这个订单。我在代码评审时看到这里当时心里想的就是把安全设计寄希望于“前端不传坏数据”早晚要出事。6. 常见问题与排查技巧实录平时被问得最多的几个问题我整理一下给你一份速查级别的实操笔记。都是踩过坑之后才总结出来的东西字不多但每一条都顶用。6.1 为什么扫描器扫不到越权问题因为越权是业务逻辑层面的问题扫描器看不到业务逻辑。工具只能识别通用的攻击特征比如把SQL注入的Payload打到输入框里看是否报错但它不明白“订单A只能由用户B查看”这个业务规则。想发现越权只有靠人工梳理业务流程逐个接口去验证权限校验是否有效或者借助一些半自动化的越权检测工具配合手工尝试。6.2 漏洞修复后为什么又被报出来这通常有两个原因。一是修复不彻底只堵了上报的那一条路径同一个功能的其他入口没管攻击者换个请求方式又进去了。二是修复方案本身引入了新问题典型的例子是原先的注入修复用过滤引号来防注入结果过滤逻辑没覆盖全或者过滤条件可以被编码绕过。真正稳妥的修复思路是使用“安全的默认行为”比如参数化查询、输出编码而不是依赖“危险的输入过滤”。6.3 同一个CVE编号为什么两家扫描器报的结果不一样扫描器对漏洞检测的覆盖范围和判断逻辑不同有的偏保守、有的偏激进有的只是做版本比对而有的做了实际验证。所以看到A扫描器报高危、B扫描器报中危甚至不报先别急着下结论。正确做法是去NVD或CNVD上看这个漏洞的官方描述和技术细节再结合自己系统的实际暴露情况来判断。工具只是辅助真正做决策的还是人。6.4 新漏洞爆发时应该先处理哪一批我的建议是按“互联网暴露面 漏洞可利用性 是否已有在野利用”来排优先级。纯内网系统、又没有人能接触到那即使CVSS分数很高也可以稍微往后放相反一个对外提供服务的登录接口被爆出可远程利用的漏洞哪怕CVSS只有7.5也得第一时间处理。这里我一般会参考CISA的KEV已知被利用漏洞目录和奇安信、深信服这些厂商的事件通告它们会标注哪些漏洞已经被真实攻击利用。6.5 想学弱点基础知识从哪下手最快先把本文提到的CVE、CWE、CVSS这三套体系搞明白然后去CWE官网上把Top 25最危险的弱点类型逐个啃一遍。每看一个类型就去找一个真实漏洞案例对照分析——去复现它、看懂它的成因、想想修复方案是什么。这样学一个类型比囫囵吞枣看一百个漏洞通告都管用。7. 这几点虽然基础但我想再多啰嗦两句说到这儿该讲的知识点都讲完了但我还是想再分享一点个人的体会。我刚开始接触安全的时候特别迷恋追各种新漏洞觉得能跟着别人复现一个高危漏洞的利用过程特别有成就感。后来工作时间长了才明白那些花里胡哨的技巧都建立在地基之上——你连SQL注入的根因都说不清楚就算拿到了新的利用链也只是知其然不知其所以然。本系列叫“弱点基础知识”我没有刻意加花活就是因为这块内容本身就已经足够值钱只是太多人不愿意沉下心来看。另外一个体会是弱点知识不只是安全从业者的功课。开发人员如果懂弱点写代码的时候就会下意识地避开很多坑运维人员如果懂弱点处理漏洞通告的时候就不会眉毛胡子一把抓。安全这件事从来不是某一个人的专属职责而是团队整体的认知水平。最后送大家一句我常和新人说的话工具可以帮你扩大视野但基础知识和业务理解才是真正拉开差距的地方。你多懂一点弱点原理就能在攻防对抗里多想一步而往往就是这一步直接决定了你是踩坑的人还是填坑的人。