开篇为什么等保测评翻来覆去就是这几个漏洞做等保测评这行时间长了你会发现一个特别有意思的规律不管被测单位是政府机构、医院、学校还是互联网公司最终测评报告里出现的高频漏洞惊人地一致。弱口令、补丁不更新、日志没开、备份没做……翻来覆去就是这些老面孔。这篇文章我会把这几年测评中几乎每次都能撞见的10个高频漏洞完整梳理一遍每个漏洞都按漏洞是什么、为什么测评师盯上它、怎么验证、怎么整改四步拆开讲还会补充实际测评中容易踩的坑。不管你是刚接触等保等保的小白还是要牵头做整改的运维负责人这份清单都能直接拿来当操作手册用。先说清楚一个底层逻辑等保2.0的测评不是站在攻击者的角度帮你找安全漏洞本身而是按照国家标准检查你是否落实了相应的安全控制措施。换句话说测评师关注的是该做的安全机制做没做、有没有效这就决定了高频漏洞往往不是那些花里胡哨的0day而是基础安全措施没做到位导致的基础病。下面这10个漏洞归根结底都是这个原因。1. 等保测评到底在查什么先搞懂测评逻辑想要理解这10个高频漏洞为什么会频繁出现得先弄明白等保2.0的测评框架。整个测评体系分为安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心、安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理共十个层面每个层面又拆成多个控制点比如身份鉴别、访问控制、安全审计、入侵防范、数据备份恢复等。测评师在现场做的核心工作就是拿着控制点清单一项一项验证。验证方式主要有三类检查配置登录服务器、数据库、网络设备查看当前的策略配置是否符合要求。访谈人员和系统管理员、安全管理员、运维人员沟通核实制度流程是否落实到位。测试验证漏扫、渗透测试、日志核查验证安全措施是否真的有效。理解了这套逻辑你应该就能明白为什么弱口令、补丁缺失这类问题永远排在高频榜前列——因为这些是安全计算环境层面最基础的控制点几乎每个被测系统都有只要有一条不符合就算不合规自然命中率极高。需要特别提醒一点很多单位觉得等保测评就是找漏洞整改完就完事了。实际上测评的重点在于持续合规比如今年通过了测评拿到了备案证明但明年抽查发现密码策略被改成弱策略了、补丁半年没打了照样能给你判定为不符合。所以后面讲整改建议时我特别强调可持续运营的视角而不是应付测评的一锤子买卖。2. 漏洞一至五身份鉴别与访问控制领域的高频问题2.1 弱口令与默认口令弱口令是整个等保测评里出现频率最高的问题每次测评几乎都能遇到后台管理系统的admin/admin123、数据库的root/root、运维主机的默认密码没改。等保2.0在身份鉴别控制点明确要求应对登录的用户进行身份标识和鉴别身份标识具有唯一性身份鉴别信息具有复杂度要求并定期更换。这里有个常见误区很多运维人员觉得我这个系统只有内部人员能用外网访问不到不会被暴力破解。测评师看问题从来不看是不是内网只看你有没有落实复杂度策略。客户说我们口令很复杂结果一看服务器上的/etc/shadow或者Windows的密码策略最短密码长度8位、只要求数字或字母一种类型直接判定不符合。在验证时测评师会做三件事查看密码策略配置、尝试用常见弱口令和默认口令登录、询问管理员口令更换周期。其中默认口令这一项经常被忽略比如某厂商设备出厂密码admin上线后没有修改一旦设备暴露在互联网上被扫到基本等于沦陷。我遇到过某单位的视频监控平台用的是某厂商的默认端口和默认密码扫描器一把就进去了能看到全部摄像头的实时画面场景相当惊悚。整改建议分三步设置密码复杂度策略大写字母小写字母数字特殊字符至少8位、强制首次登录修改初始口令、建立口令定期更换机制建议周期为90天涉密系统可缩短至30天。对于设备资产较多的单位建议配合密码管理系统做统一纳管避免运维人员把口令记在Excel里。2.2 操作系统与中间件的已知高危漏洞未修复这个漏洞在等级保护测评中的判定逻辑是被测对象是否存在中高危级别的已知安全漏洞且未采取有效处置措施。常见的案例包括Windows服务器存在永恒之蓝对应漏洞、Linux内核版本过旧存在提权漏洞、中间件如Web应用中间件存在反序列化远程代码执行漏洞、数据库存在默认口令漏洞等。为什么这类问题如此高频核心原因在于很多系统的上线时间是很多年前稳定压倒一切的运维思路导致补丁更新极度保守。我见过一台存放业务数据的服务器Windows Server 2003系统、补丁停留在5年前一看系统版本我心里就咯噔一下——等保测评里漏洞扫描这块大概率会亮起一片红。检测方法通常是依靠漏扫工具常见开源工具有OpenVAS商业工具有各类综合扫描器加手工验证。测评师会把扫描报告和核查结果记录到记录表中并对照漏洞级别区分高风险、中风险和低风险其中高危漏洞若不整改直接判不符合。整改方案说难并不难及时安装补丁、升级软件版本、对于暂时无法升级的系统配置安全策略进行缓解比如关闭高危端口、移除高危组件、在网络边界部署安全防护设备拦截攻击载荷。这里特别重要的一点是等保测评认可的整改完成不是厂家说打了补丁就行而是测评师复测时看到补丁已安装、漏洞扫描确实已消失。所以整改后一定要让测评师复测别改完了就晾在那儿等报告。2.3 登录失败策略缺失登录失败策略是等保测评里另一个常见的身份鉴别高频项。要求是应对同一用户多次登录失败的情况进行处理例如账户锁定或登录延迟。不少单位觉得只要有复杂的密码策略就够了忽略了登录失败处理。实际中我经常看到的情况是Windows服务器的账户锁定阈值设置为0即不锁定Linux服务器的SSH配置里没有失败延迟或者Web管理后台没有任何验证码和失败次数限制。这种配置等于告诉攻击者你可以无限次暴力破解我不会拦你。验证方法直截了当连上服务器查看组策略或相关配置连续输错几次密码测试有没有触发锁定查看应用系统配置文件里有没有锁定阈值参数对互联网业务系统测试验证码是否存在失效机制。整改其实不复杂Windows系统在安全策略中设置账户锁定阈值为5次、锁定时间30分钟Linux系统可在PAM认证模块中配置pam_faillock模块Web系统可加入图形验证码、短信验证码、登录失败次数限制。需要小心的是账户锁定策略可能带来大量账号被锁定的问题特别是如果单位存在共享账号几个运维同事用同一个账号失败几次导致全体无法登录。为了兼顾安全和可用性可以设置一个合适的阈值比如5到10次同时配置锁定时间不要太长并明确解锁流程。2.4 访问控制策略不当导致越权风险等保2.0在访问控制控制点上有明确要求应对登录的用户分配账户和权限并实现用户权限分离也就是按最小权限原则分配。访问控制策略不当的表现形式有很多存在默认共享且未设置访问限制、目录具备任何人都可写入的权限、应用程序中权限校验缺失可以越权查看其他用户数据、用户组权限设置过于宽泛。这类问题在业务系统渗透测试中尤其容易发现测评师可能用低权限账号尝试访问管理接口路径或在登录状态下直接修改URL中的用户ID参数成功访问到其他用户的数据——这就是水平越权。在验证时测评师会核实系统管理员、安全管理员、审计管理员是否三权分立查看应用系统是否存在不必要的匿名访问或默认共享有条件的还会进行越权测试。曾经在某单位的OA系统中测评师发现普通用户可以直接在浏览器地址栏构造URL访问后台管理页面配合弱口令直接就进管理后台了整个单位的组织结构、公文文件全都能看这种问题在测评里基本是无法通过的。整改方案的理念就是用最小权限原则来梳理逐一排查系统账号和权限删除无用账号设置文件夹和数据库访问控制ACL关闭默认共享开发侧对接口做统一的权限校验不能只在前端做按钮隐藏。2.5 SQL注入漏洞SQL注入是渗透测试中最常见的Web应用漏洞之一在等保测评中通常对应安全计算环境的入侵防范和恶意代码防范控制点。原理非常简单Web应用未对用户输入进行过滤和参数化处理直接把输入拼接进SQL查询语句导致攻击者可以修改数据库查询逻辑。测SQL注入的方法很成熟使用漏扫工具对目标URL进行扫描或使用Burp Suite手动抓包测试在输入框或参数中提交单引号等特殊字符观察数据库报错信息再使用注入payload验证是否存在漏洞。这类漏洞整改要从根上解决使用预编译语句参数化查询对用户输入做严格的白名单校验部署Web应用防火墙进行攻击拦截并和开发团队做好日志联动上线前进行应用安全测试。但现实里值得说明的现象是很多单位老旧系统代码是外包写的源码都不一定找得到根本没法改。对这类系统通常建议在网络边界用WAF拦截同时严格限制Web应用所在服务器的外联访问权限避免被拖库后数据直接外传。虽然不算根治但测评现场核对防护措施后可以依据整体补偿措施进行评估。3. 漏洞六至十Web安全、审计与数据安全高频项3.1 存储型与反射型XSS跨站脚本XSS漏洞在等保测评的Web系统测试中出现概率同样不低和SQL注入一样都是应用开发不规范导致的。由于能在受害者的浏览器中执行脚本XSS常被用来窃取Cookie、会话劫持、钓鱼或篡改页面内容。测评师会测两类XSS反射型通过URL参数即时触发和存储型把恶意脚本持久化到服务器任何访问该页面的用户都会触发。存储型XSS因为危害更大在测评中判得也更重。检测时通常在表单输入和URL参数中提交带有标记的脚本payload然后在浏览器中观察是否弹出提示框、是否加载了外部图片。只要弹框出来了基本就可以确认漏洞存在。整改方法以输出编码和输入过滤为主在服务端对输出到HTML的上下文做编码处理对输入做长度和字符集限制设置Cookie的HttpOnly属性和SameSite属性。另外现代开发框架如Vue、React自带一定的XSS防护能力关键是要确保项目中没有关闭掉默认的转义机制。3.2 敏感信息泄露敏感信息泄露涵盖的范围比较广HTTP响应头暴露服务器版本信息、目录浏览功能未关闭、备份文件或源码包遗留在Web目录下、报错页面泄露SQL语句和绝对路径、前端页面源码中存在内部IP或账号信息。等保测评中看到这类问题的常见场景通过浏览器直接访问某个目录路径返回了文件列表其中包含一份数据库备份文件点击下载就能拿下来或者访问一个不存在的页面报错信息直接把数据库连接字符串打到页面上了。验证方法是浏览网站目录结构、查看HTTP响应头Server字段、访问已知敏感路径如/.git、/backup、/upload、触发错误页面观察返回内容。整改工作包括禁用目录浏览、配置友好的错误页面、清理Web目录中的备份文件和无用文件、隐藏服务版本信息、修改默认的管理入口路径。对测试环境的访问要做好访问控制特别是对互联网侧的目录枚举。3.3 日志审计不完整或未开启等保2.0对安全审计控制点的要求是应启用安全审计功能审计覆盖到每个用户对重要用户行为和重要安全事件进行审计。换言之你得知道在系统上是谁、在什么时间、做了什么操作。很多违规单位都是在等保测评时才发现自己裸奔了Windows系统没有开启审核策略、Linux服务器没有配置远程日志服务器、Web应用日志没有记录访问来源和请求URI、数据库审计日志保存时间只有几天就覆盖了。判定日志审计是否合规测评师会看四件事第一是否开启了系统、应用、数据库的审计功能第二审计范围是否覆盖了所有用户第三日志内容是否包含用户标识、时间、操作类型、结果第四日志保存时间是否满足要求国家标准一般建议留存不少于6个月有些行业标准要求留存更久。整改建议包括开启系统安全审计Windows组策略中的审核策略Linux的syslog/rsyslog在Web中间件配置层面开启访问日志和错误日志数据库启用审计功能如无法开启则使用旁路审计设备搭建统一日志平台或集中日志服务器将各类日志集中收集、轮转和保存。这里有一个比较容易忽略的实践问题很多人以为开了日志就行但没有测试日志是否会滚动覆盖。某单位Web日志配置了按天轮转但只保留7天结果半年后测评师来查历史操作的审计记录时日志早就清空了只能被判定不符合。日志能不能查得出来比开没开日志本身更重要。3.4 数据备份与恢复机制缺失数据备份恢复控制点虽然没有身份鉴别、访问控制出现得那么密集但一旦出现就一定是不符合项。等保测评要求系统应提供本地数据备份和恢复功能重要数据应实现异地备份或高可用容灾机制。实际排查中发现的问题五花八门只做了单块硬盘的RAID 1认为这就是备份了备份脚本写好了但没有定期执行备份数据存储在同一台服务器的另一块磁盘上系统挂了备份也没了从未做过恢复演练备份数据能不能还原没人知道。关于备份和高可用的区别很多运维人员容易搞混。RAID冗余不是备份双机热备不是备份只有把数据复制到独立的存储介质上并且能够从复制数据中恢复业务才算是备份。测评时测评师会查看备份策略文档、备份执行记录和恢复演练报告。如果没有恢复演练记录通常也会被认为未落实数据备份恢复要求。整改方案需要三个要点本地备份策略每日增量、每周全量、异地备份至少配置到不同机房或存储设备、定期恢复演练建议每半年一次。备份系统本身的安全也需要考虑备份数据应当加密保存备份系统账号要与业务系统账号隔离。3.5 文件上传漏洞文件上传漏洞在等保测评的Web应用安全测试里极其致命因为它可以直接演变成远程控制。只要应用允许用户上传文件头像、附件、导入文件等且没有对文件类型做严格校验攻击者能上传一个可执行脚本文件也就是常说的WebShell然后通过访问该文件获得服务器的命令执行权限。等保测评中曾遇到一个典型案例某单位系统存在文件上传功能直接上传一个PHP文件就能访问结合服务器中间件解析漏洞最终打通了内网。这种漏洞在现场渗透测试中常常是突破口从上传点一路打穿到核心业务系统。测试方法是用Burp Suite拦截上传请求修改文件扩展名和Content-Type尝试上传可执行脚本观察上传后的文件访问路径确认是否能直接访问并执行。整改方案的核心是白名单校验文件扩展名和MIME类型、对上传文件重命名不要使用用户可控文件名、随机化存储目录、上传目录禁止执行脚本权限、对上传文件做内容安全检测。4. 实操中如何高效发现并落地整改一个完整流程前面分门别类介绍了10个漏洞但放到真实的整改项目里流程又是另一回事。很多单位等保测评不过不是缺攻坚能力而是整个流程一团乱麻。下面我完整走一遍我在项目里验证过多次的整改流程。第一步资产梳理与范围确认测评整改的第一步不是急着扫漏洞而是把所有在测评范围内的资产盘点清楚。包括服务器操作系统、数据库、中间件、应用系统、网络设备、安全设备、终端和机房物理环境。建议做一张资产清单表列清IP地址、负责人、系统版本、开放端口、部署位置。这一步决定后续漏扫的覆盖面有没有遗漏。第二步漏扫加手工验证双管齐下漏扫和手工验证必须结合漏扫能覆盖已知CVE漏洞的检测快速发现补丁缺失等明显问题手工验证则针对逻辑漏洞越权、业务逻辑缺陷和误报筛选同时验证漏扫报告里的高危项是否真实有效。实际中我的做法是用至少两种扫描器交叉验证避免单款工具漏扫和误报扫描到的高危项逐个手工复现确认可利用性同时登录服务器查看关键配置项对照等保要求逐项走查。第三步分类分级制定整改优先级整改顺序不要眉毛胡子一把抓。我的建议分三级处理第一优先可被利用且容易打成命令执行的高危项如SQL注入、文件上传必须立刻改。第二优先基础配置类不合规项如弱口令、登录失败策略缺失这类改起来快、效果明显。第三优先管理类和长期建设类项如日志集中平台、备份恢复机制这类整改周期长尽早规划。第四步整改与复测闭环整改完不是就算结束了必须和测评机构约定复测时间、重新验证整改有效性。复测时带上整改证据配置截图、测试报告、操作记录。这里有个实践经验整改证据最好按测评报告的条款编号逐一对应列出来测评师复测起来效率高也显得整改工作扎实。5. 常见问题速查与踩坑实录为了让你少走弯路我把和这10个漏洞相关的常见问题整理成速查表再补充几个实际项目中反复趟过的坑。问题现象常见原因对应排查方法整改方向系统账号密码被暴力破解密码复杂度不足、无锁定策略查看密码策略和账户锁定配置设置复杂度锁定策略漏扫报告一片红补丁长期未更新、版本过旧使用扫描器交叉验证并手动确认补齐补丁升级版本Web应用被入侵后找不到痕迹日志没开、日志被关闭检查中间件审计日志是否开启开启访问日志并集中收集业务系统API可越权访问权限校验缺失手工修改参数测试越权统一权限校验、三权分立备份文件下载即得目录浏览开启、备份置于Web目录浏览URL路径确认是否列目录禁用目录浏览、转移备份文件数据库被人拖库SQL注入权限过大漏扫加SQL注入手工验证参数化查询数据库账号降权管理员操作无记录审计功能关闭、管理后台无审计查看安全审计策略是否开启开启三权分立审计系统上线后突然无法登录锁定策略误配置导致账号被锁检查锁定策略是否过于激进设置合理阈值与解锁流程几个实操心得严格来说是每一条都是真实趟出来的。好多单位在整改时只会做堵的动作比如把危险端口封掉、把弱口令改掉但不去看业务侧的真实需求。最典型的就是关端口关到业务起不来最后又悄悄把端口打开等于没改。整改要考虑业务可用性比如数据库不能用高权限账号跑业务但也不能直接一刀切把权限全去掉导致系统崩溃需要和开发团队仔细确认每个连接串的权限需求。第二个坑是重整改、轻证据逻辑。测评师复测时你空口说已经改了没用对方要看到证据配置截图要带服务器时间扫描报告要显示漏洞消失备份恢复要拿得出演练记录。我在项目里专门让整改小组建立一个总的等保整改证据文件夹按控制点编号分类存放截图和文档最后交付测评机构时非常顺畅。第三个坑是很多单位只盯着技术整改忽略了管理制度的落地。比如安全审计要求日志留存6个月技术层面搭了日志系统但没有人负责定期检查日志是否正常写入没有日志审计流程测评时访谈安全管理员一问三不知还是被判定不符合。技术和管理两条腿必须同时走。写在最后这10个高频漏洞的相似之处在于它们都不难修难的是坚持长期运维不松懈。等保测评不是终点它只是一次体检报告把报告里的问题一个个改完再把对应的管理制度立起来、执行下去这才是这套机制真正想帮你达成的目标。最后分享一个我觉得非常有效的操作习惯每个季度把上面这张速查表拿出来照着自查一遍用不了半天时间但能保证下次测评或检查时不会出现那种早就提醒过却没人管的低级不合规项。希望这篇整理对你有用。 
长河君 · 2026/10/20 6:47:32 · 阅读 1.2k 等保测评高频漏洞全解析：从弱口令到SQL注入的整改实战指南
开篇为什么等保测评翻来覆去就是这几个漏洞做等保测评这行时间长了你会发现一个特别有意思的规律不管被测单位是政府机构、医院、学校还是互联网公司最终测评报告里出现的高频漏洞惊人地一致。弱口令、补丁不更新、日志没开、备份没做……翻来覆去就是这些老面孔。这篇文章我会把这几年测评中几乎每次都能撞见的10个高频漏洞完整梳理一遍每个漏洞都按漏洞是什么、为什么测评师盯上它、怎么验证、怎么整改四步拆开讲还会补充实际测评中容易踩的坑。不管你是刚接触等保等保的小白还是要牵头做整改的运维负责人这份清单都能直接拿来当操作手册用。先说清楚一个底层逻辑等保2.0的测评不是站在攻击者的角度帮你找安全漏洞本身而是按照国家标准检查你是否落实了相应的安全控制措施。换句话说测评师关注的是该做的安全机制做没做、有没有效这就决定了高频漏洞往往不是那些花里胡哨的0day而是基础安全措施没做到位导致的基础病。下面这10个漏洞归根结底都是这个原因。1. 等保测评到底在查什么先搞懂测评逻辑想要理解这10个高频漏洞为什么会频繁出现得先弄明白等保2.0的测评框架。整个测评体系分为安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心、安全管理制度、安全管理机构、安全管理人员、安全建设管理、安全运维管理共十个层面每个层面又拆成多个控制点比如身份鉴别、访问控制、安全审计、入侵防范、数据备份恢复等。测评师在现场做的核心工作就是拿着控制点清单一项一项验证。验证方式主要有三类检查配置登录服务器、数据库、网络设备查看当前的策略配置是否符合要求。访谈人员和系统管理员、安全管理员、运维人员沟通核实制度流程是否落实到位。测试验证漏扫、渗透测试、日志核查验证安全措施是否真的有效。理解了这套逻辑你应该就能明白为什么弱口令、补丁缺失这类问题永远排在高频榜前列——因为这些是安全计算环境层面最基础的控制点几乎每个被测系统都有只要有一条不符合就算不合规自然命中率极高。需要特别提醒一点很多单位觉得等保测评就是找漏洞整改完就完事了。实际上测评的重点在于持续合规比如今年通过了测评拿到了备案证明但明年抽查发现密码策略被改成弱策略了、补丁半年没打了照样能给你判定为不符合。所以后面讲整改建议时我特别强调可持续运营的视角而不是应付测评的一锤子买卖。2. 漏洞一至五身份鉴别与访问控制领域的高频问题2.1 弱口令与默认口令弱口令是整个等保测评里出现频率最高的问题每次测评几乎都能遇到后台管理系统的admin/admin123、数据库的root/root、运维主机的默认密码没改。等保2.0在身份鉴别控制点明确要求应对登录的用户进行身份标识和鉴别身份标识具有唯一性身份鉴别信息具有复杂度要求并定期更换。这里有个常见误区很多运维人员觉得我这个系统只有内部人员能用外网访问不到不会被暴力破解。测评师看问题从来不看是不是内网只看你有没有落实复杂度策略。客户说我们口令很复杂结果一看服务器上的/etc/shadow或者Windows的密码策略最短密码长度8位、只要求数字或字母一种类型直接判定不符合。在验证时测评师会做三件事查看密码策略配置、尝试用常见弱口令和默认口令登录、询问管理员口令更换周期。其中默认口令这一项经常被忽略比如某厂商设备出厂密码admin上线后没有修改一旦设备暴露在互联网上被扫到基本等于沦陷。我遇到过某单位的视频监控平台用的是某厂商的默认端口和默认密码扫描器一把就进去了能看到全部摄像头的实时画面场景相当惊悚。整改建议分三步设置密码复杂度策略大写字母小写字母数字特殊字符至少8位、强制首次登录修改初始口令、建立口令定期更换机制建议周期为90天涉密系统可缩短至30天。对于设备资产较多的单位建议配合密码管理系统做统一纳管避免运维人员把口令记在Excel里。2.2 操作系统与中间件的已知高危漏洞未修复这个漏洞在等级保护测评中的判定逻辑是被测对象是否存在中高危级别的已知安全漏洞且未采取有效处置措施。常见的案例包括Windows服务器存在永恒之蓝对应漏洞、Linux内核版本过旧存在提权漏洞、中间件如Web应用中间件存在反序列化远程代码执行漏洞、数据库存在默认口令漏洞等。为什么这类问题如此高频核心原因在于很多系统的上线时间是很多年前稳定压倒一切的运维思路导致补丁更新极度保守。我见过一台存放业务数据的服务器Windows Server 2003系统、补丁停留在5年前一看系统版本我心里就咯噔一下——等保测评里漏洞扫描这块大概率会亮起一片红。检测方法通常是依靠漏扫工具常见开源工具有OpenVAS商业工具有各类综合扫描器加手工验证。测评师会把扫描报告和核查结果记录到记录表中并对照漏洞级别区分高风险、中风险和低风险其中高危漏洞若不整改直接判不符合。整改方案说难并不难及时安装补丁、升级软件版本、对于暂时无法升级的系统配置安全策略进行缓解比如关闭高危端口、移除高危组件、在网络边界部署安全防护设备拦截攻击载荷。这里特别重要的一点是等保测评认可的整改完成不是厂家说打了补丁就行而是测评师复测时看到补丁已安装、漏洞扫描确实已消失。所以整改后一定要让测评师复测别改完了就晾在那儿等报告。2.3 登录失败策略缺失登录失败策略是等保测评里另一个常见的身份鉴别高频项。要求是应对同一用户多次登录失败的情况进行处理例如账户锁定或登录延迟。不少单位觉得只要有复杂的密码策略就够了忽略了登录失败处理。实际中我经常看到的情况是Windows服务器的账户锁定阈值设置为0即不锁定Linux服务器的SSH配置里没有失败延迟或者Web管理后台没有任何验证码和失败次数限制。这种配置等于告诉攻击者你可以无限次暴力破解我不会拦你。验证方法直截了当连上服务器查看组策略或相关配置连续输错几次密码测试有没有触发锁定查看应用系统配置文件里有没有锁定阈值参数对互联网业务系统测试验证码是否存在失效机制。整改其实不复杂Windows系统在安全策略中设置账户锁定阈值为5次、锁定时间30分钟Linux系统可在PAM认证模块中配置pam_faillock模块Web系统可加入图形验证码、短信验证码、登录失败次数限制。需要小心的是账户锁定策略可能带来大量账号被锁定的问题特别是如果单位存在共享账号几个运维同事用同一个账号失败几次导致全体无法登录。为了兼顾安全和可用性可以设置一个合适的阈值比如5到10次同时配置锁定时间不要太长并明确解锁流程。2.4 访问控制策略不当导致越权风险等保2.0在访问控制控制点上有明确要求应对登录的用户分配账户和权限并实现用户权限分离也就是按最小权限原则分配。访问控制策略不当的表现形式有很多存在默认共享且未设置访问限制、目录具备任何人都可写入的权限、应用程序中权限校验缺失可以越权查看其他用户数据、用户组权限设置过于宽泛。这类问题在业务系统渗透测试中尤其容易发现测评师可能用低权限账号尝试访问管理接口路径或在登录状态下直接修改URL中的用户ID参数成功访问到其他用户的数据——这就是水平越权。在验证时测评师会核实系统管理员、安全管理员、审计管理员是否三权分立查看应用系统是否存在不必要的匿名访问或默认共享有条件的还会进行越权测试。曾经在某单位的OA系统中测评师发现普通用户可以直接在浏览器地址栏构造URL访问后台管理页面配合弱口令直接就进管理后台了整个单位的组织结构、公文文件全都能看这种问题在测评里基本是无法通过的。整改方案的理念就是用最小权限原则来梳理逐一排查系统账号和权限删除无用账号设置文件夹和数据库访问控制ACL关闭默认共享开发侧对接口做统一的权限校验不能只在前端做按钮隐藏。2.5 SQL注入漏洞SQL注入是渗透测试中最常见的Web应用漏洞之一在等保测评中通常对应安全计算环境的入侵防范和恶意代码防范控制点。原理非常简单Web应用未对用户输入进行过滤和参数化处理直接把输入拼接进SQL查询语句导致攻击者可以修改数据库查询逻辑。测SQL注入的方法很成熟使用漏扫工具对目标URL进行扫描或使用Burp Suite手动抓包测试在输入框或参数中提交单引号等特殊字符观察数据库报错信息再使用注入payload验证是否存在漏洞。这类漏洞整改要从根上解决使用预编译语句参数化查询对用户输入做严格的白名单校验部署Web应用防火墙进行攻击拦截并和开发团队做好日志联动上线前进行应用安全测试。但现实里值得说明的现象是很多单位老旧系统代码是外包写的源码都不一定找得到根本没法改。对这类系统通常建议在网络边界用WAF拦截同时严格限制Web应用所在服务器的外联访问权限避免被拖库后数据直接外传。虽然不算根治但测评现场核对防护措施后可以依据整体补偿措施进行评估。3. 漏洞六至十Web安全、审计与数据安全高频项3.1 存储型与反射型XSS跨站脚本XSS漏洞在等保测评的Web系统测试中出现概率同样不低和SQL注入一样都是应用开发不规范导致的。由于能在受害者的浏览器中执行脚本XSS常被用来窃取Cookie、会话劫持、钓鱼或篡改页面内容。测评师会测两类XSS反射型通过URL参数即时触发和存储型把恶意脚本持久化到服务器任何访问该页面的用户都会触发。存储型XSS因为危害更大在测评中判得也更重。检测时通常在表单输入和URL参数中提交带有标记的脚本payload然后在浏览器中观察是否弹出提示框、是否加载了外部图片。只要弹框出来了基本就可以确认漏洞存在。整改方法以输出编码和输入过滤为主在服务端对输出到HTML的上下文做编码处理对输入做长度和字符集限制设置Cookie的HttpOnly属性和SameSite属性。另外现代开发框架如Vue、React自带一定的XSS防护能力关键是要确保项目中没有关闭掉默认的转义机制。3.2 敏感信息泄露敏感信息泄露涵盖的范围比较广HTTP响应头暴露服务器版本信息、目录浏览功能未关闭、备份文件或源码包遗留在Web目录下、报错页面泄露SQL语句和绝对路径、前端页面源码中存在内部IP或账号信息。等保测评中看到这类问题的常见场景通过浏览器直接访问某个目录路径返回了文件列表其中包含一份数据库备份文件点击下载就能拿下来或者访问一个不存在的页面报错信息直接把数据库连接字符串打到页面上了。验证方法是浏览网站目录结构、查看HTTP响应头Server字段、访问已知敏感路径如/.git、/backup、/upload、触发错误页面观察返回内容。整改工作包括禁用目录浏览、配置友好的错误页面、清理Web目录中的备份文件和无用文件、隐藏服务版本信息、修改默认的管理入口路径。对测试环境的访问要做好访问控制特别是对互联网侧的目录枚举。3.3 日志审计不完整或未开启等保2.0对安全审计控制点的要求是应启用安全审计功能审计覆盖到每个用户对重要用户行为和重要安全事件进行审计。换言之你得知道在系统上是谁、在什么时间、做了什么操作。很多违规单位都是在等保测评时才发现自己裸奔了Windows系统没有开启审核策略、Linux服务器没有配置远程日志服务器、Web应用日志没有记录访问来源和请求URI、数据库审计日志保存时间只有几天就覆盖了。判定日志审计是否合规测评师会看四件事第一是否开启了系统、应用、数据库的审计功能第二审计范围是否覆盖了所有用户第三日志内容是否包含用户标识、时间、操作类型、结果第四日志保存时间是否满足要求国家标准一般建议留存不少于6个月有些行业标准要求留存更久。整改建议包括开启系统安全审计Windows组策略中的审核策略Linux的syslog/rsyslog在Web中间件配置层面开启访问日志和错误日志数据库启用审计功能如无法开启则使用旁路审计设备搭建统一日志平台或集中日志服务器将各类日志集中收集、轮转和保存。这里有一个比较容易忽略的实践问题很多人以为开了日志就行但没有测试日志是否会滚动覆盖。某单位Web日志配置了按天轮转但只保留7天结果半年后测评师来查历史操作的审计记录时日志早就清空了只能被判定不符合。日志能不能查得出来比开没开日志本身更重要。3.4 数据备份与恢复机制缺失数据备份恢复控制点虽然没有身份鉴别、访问控制出现得那么密集但一旦出现就一定是不符合项。等保测评要求系统应提供本地数据备份和恢复功能重要数据应实现异地备份或高可用容灾机制。实际排查中发现的问题五花八门只做了单块硬盘的RAID 1认为这就是备份了备份脚本写好了但没有定期执行备份数据存储在同一台服务器的另一块磁盘上系统挂了备份也没了从未做过恢复演练备份数据能不能还原没人知道。关于备份和高可用的区别很多运维人员容易搞混。RAID冗余不是备份双机热备不是备份只有把数据复制到独立的存储介质上并且能够从复制数据中恢复业务才算是备份。测评时测评师会查看备份策略文档、备份执行记录和恢复演练报告。如果没有恢复演练记录通常也会被认为未落实数据备份恢复要求。整改方案需要三个要点本地备份策略每日增量、每周全量、异地备份至少配置到不同机房或存储设备、定期恢复演练建议每半年一次。备份系统本身的安全也需要考虑备份数据应当加密保存备份系统账号要与业务系统账号隔离。3.5 文件上传漏洞文件上传漏洞在等保测评的Web应用安全测试里极其致命因为它可以直接演变成远程控制。只要应用允许用户上传文件头像、附件、导入文件等且没有对文件类型做严格校验攻击者能上传一个可执行脚本文件也就是常说的WebShell然后通过访问该文件获得服务器的命令执行权限。等保测评中曾遇到一个典型案例某单位系统存在文件上传功能直接上传一个PHP文件就能访问结合服务器中间件解析漏洞最终打通了内网。这种漏洞在现场渗透测试中常常是突破口从上传点一路打穿到核心业务系统。测试方法是用Burp Suite拦截上传请求修改文件扩展名和Content-Type尝试上传可执行脚本观察上传后的文件访问路径确认是否能直接访问并执行。整改方案的核心是白名单校验文件扩展名和MIME类型、对上传文件重命名不要使用用户可控文件名、随机化存储目录、上传目录禁止执行脚本权限、对上传文件做内容安全检测。4. 实操中如何高效发现并落地整改一个完整流程前面分门别类介绍了10个漏洞但放到真实的整改项目里流程又是另一回事。很多单位等保测评不过不是缺攻坚能力而是整个流程一团乱麻。下面我完整走一遍我在项目里验证过多次的整改流程。第一步资产梳理与范围确认测评整改的第一步不是急着扫漏洞而是把所有在测评范围内的资产盘点清楚。包括服务器操作系统、数据库、中间件、应用系统、网络设备、安全设备、终端和机房物理环境。建议做一张资产清单表列清IP地址、负责人、系统版本、开放端口、部署位置。这一步决定后续漏扫的覆盖面有没有遗漏。第二步漏扫加手工验证双管齐下漏扫和手工验证必须结合漏扫能覆盖已知CVE漏洞的检测快速发现补丁缺失等明显问题手工验证则针对逻辑漏洞越权、业务逻辑缺陷和误报筛选同时验证漏扫报告里的高危项是否真实有效。实际中我的做法是用至少两种扫描器交叉验证避免单款工具漏扫和误报扫描到的高危项逐个手工复现确认可利用性同时登录服务器查看关键配置项对照等保要求逐项走查。第三步分类分级制定整改优先级整改顺序不要眉毛胡子一把抓。我的建议分三级处理第一优先可被利用且容易打成命令执行的高危项如SQL注入、文件上传必须立刻改。第二优先基础配置类不合规项如弱口令、登录失败策略缺失这类改起来快、效果明显。第三优先管理类和长期建设类项如日志集中平台、备份恢复机制这类整改周期长尽早规划。第四步整改与复测闭环整改完不是就算结束了必须和测评机构约定复测时间、重新验证整改有效性。复测时带上整改证据配置截图、测试报告、操作记录。这里有个实践经验整改证据最好按测评报告的条款编号逐一对应列出来测评师复测起来效率高也显得整改工作扎实。5. 常见问题速查与踩坑实录为了让你少走弯路我把和这10个漏洞相关的常见问题整理成速查表再补充几个实际项目中反复趟过的坑。问题现象常见原因对应排查方法整改方向系统账号密码被暴力破解密码复杂度不足、无锁定策略查看密码策略和账户锁定配置设置复杂度锁定策略漏扫报告一片红补丁长期未更新、版本过旧使用扫描器交叉验证并手动确认补齐补丁升级版本Web应用被入侵后找不到痕迹日志没开、日志被关闭检查中间件审计日志是否开启开启访问日志并集中收集业务系统API可越权访问权限校验缺失手工修改参数测试越权统一权限校验、三权分立备份文件下载即得目录浏览开启、备份置于Web目录浏览URL路径确认是否列目录禁用目录浏览、转移备份文件数据库被人拖库SQL注入权限过大漏扫加SQL注入手工验证参数化查询数据库账号降权管理员操作无记录审计功能关闭、管理后台无审计查看安全审计策略是否开启开启三权分立审计系统上线后突然无法登录锁定策略误配置导致账号被锁检查锁定策略是否过于激进设置合理阈值与解锁流程几个实操心得严格来说是每一条都是真实趟出来的。好多单位在整改时只会做堵的动作比如把危险端口封掉、把弱口令改掉但不去看业务侧的真实需求。最典型的就是关端口关到业务起不来最后又悄悄把端口打开等于没改。整改要考虑业务可用性比如数据库不能用高权限账号跑业务但也不能直接一刀切把权限全去掉导致系统崩溃需要和开发团队仔细确认每个连接串的权限需求。第二个坑是重整改、轻证据逻辑。测评师复测时你空口说已经改了没用对方要看到证据配置截图要带服务器时间扫描报告要显示漏洞消失备份恢复要拿得出演练记录。我在项目里专门让整改小组建立一个总的等保整改证据文件夹按控制点编号分类存放截图和文档最后交付测评机构时非常顺畅。第三个坑是很多单位只盯着技术整改忽略了管理制度的落地。比如安全审计要求日志留存6个月技术层面搭了日志系统但没有人负责定期检查日志是否正常写入没有日志审计流程测评时访谈安全管理员一问三不知还是被判定不符合。技术和管理两条腿必须同时走。写在最后这10个高频漏洞的相似之处在于它们都不难修难的是坚持长期运维不松懈。等保测评不是终点它只是一次体检报告把报告里的问题一个个改完再把对应的管理制度立起来、执行下去这才是这套机制真正想帮你达成的目标。最后分享一个我觉得非常有效的操作习惯每个季度把上面这张速查表拿出来照着自查一遍用不了半天时间但能保证下次测评或检查时不会出现那种早就提醒过却没人管的低级不合规项。希望这篇整理对你有用。