项目中遇到过不少次类似的场面群里忽然冒出一条消息标题写得耸人听闻核心关键词是XSS、0day、通杀所有版本还带着一个可 getshell的尾巴配图往往是半个命令行窗口。消息传得飞快转发的人绝大多数并没有真的验证过只是觉得这事挺大。作为长期在甲方做安全建设和应急的人我对这类标题的第一反应从来不是赶紧下载试试而是三个问题它描述的缺陷类型是什么、影响面到底有多大、我手上的资产有没有暴露在同样的风险结构里。这三个问题才是有价值的而怎么打进去从来不是这篇文章要谈的内容。需要把话说在前面下面所有内容都围绕防护、检测、治理和应急展开不涉及任何利用代码、注入字符串、绕过手法或入侵步骤。原因很简单任何一篇公开的通杀型利用教程最终受益的都不是防守方。真正需要被讲清楚的是为什么一类老系统会反复出现同类问题、防守方如何快速判断自身暴露面、以及在无法立刻重写系统的现实约束下怎么把风险压下去。这篇文章适合三类人看负责企业资产安全的运维和安服同学、正在维护老项目的开发者、以及对 Web 安全刚入门、容易被这类标题带偏方向的学习者。1. 通杀所有版本这句话到底在说什么1.1 同一套代码骨架衍生出的共性缺陷一款内容管理系统会被说成通杀所有版本通常不是因为它每个版本都被单独挖出了洞而是因为它的代码骨架在多个版本之间几乎没变。老牌 CMS 有一个很典型的特征核心的模板解析、参数接收、文件写入这几条链路从早期版本一直沿用下来中间只做加法不做减法。新版本加功能、改界面、修某些具体报错但那几条老链路依然躺在那里甚至连函数名都没改过。这就导致一个结果只要某个位置存在输入未过滤、输出未编码的问题那么所有继承这套骨架的版本都会中招。攻击者不需要针对每个版本单独构造因为调用路径是一样的。所谓通杀本质上是同源代码的批量复用而不是什么高深的技术突破。理解这一点非常重要因为它直接决定了防守方的应对思路——你不需要去背某个具体版本的差异你需要判断的是这条代码链路在你的部署里是否存在、是否可达。我在实际审计中见过太多类似情况一个参数从入口传进来经过两三层函数调用最后被直接拼进了页面模板中间没有任何一处做过类型约束或字符过滤。这种链路的生命力极其顽强因为它能跑而且改动它可能影响大量正常业务于是每一任维护者都选择绕开而不是修掉。技术债就是这么积累成攻击面的。1.2 XSS 到 getshell 之间隔着什么标题里最容易让人恐慌的是可 getshell。这里需要把概念拆清楚否则很容易被带节奏。XSS 是浏览器端的问题它的作用域是访问者的页面上下文getshell 是服务器端的结果作用域是操作系统。两者之间并不是一步到位的关系中间必须存在某种把前端能力转化为后端能力的桥。常见的桥有三类我用生活化的方式解释。第一类是后台身份借用管理员的浏览器被脚本影响后攻击者可以以管理员身份去操作后台功能而后台里往往存在文件管理、模板编辑这类高危能力。第二类是存储型内容落地某些位置允许写入内容并被服务端当作代码执行典型的就是模板缓存目录。第三类是凭证或会话泄露通过在页面注入脚本获取到某些令牌再用这些令牌去调用更高权限的接口。看懂这个结构的意义在于防守方不需要等全链路打通才行动。这条链上有好几个断点可以掐掐住任何一个链条就断了。最常见也最有效的断点就是后台高危功能和可写目录的可执行性。很多人只盯着 XSS 的输入过滤其实那是性价比最低的一环因为过滤规则永远在被打补丁。1.3 为什么这类标题传播快但信息量低这类标题的传播逻辑和它的技术含量几乎无关。它踩中了几个心理点通杀意味着覆盖面广让人本能觉得自己的资产可能中招0day意味着没有补丁制造紧迫感getshell是结果导向比起存在反射型 XSS这种描述威慑力大得多。三条叠在一起转发是必然的。但从信息价值看这类描述几乎没有提供任何可行动的信息。它没说触发条件、没说前置权限、没说受影响的具体功能模块、没说部署环境要求。我曾经跟进过一次类似的舆情最后核实下来那条链路要求攻击者已经具备后台低权限账号而那个环境的默认配置根本不允许自助注册。也就是说对绝大多数实际部署来说风险是收敛的。提示看到任何通杀秒杀一键字样的安全情报先按这三条过滤——是否需要前置权限、是否依赖非默认配置、是否有可验证的公开编号。三条都过不了的优先级可以往后放。2. 老旧建站系统的风险画像怎么画2.1 先搞清楚自己的资产边界所有安全工作的第一步都是资产清点但这一步恰恰是很多团队做得最糊的。我见过不止一次出事后才发现某个业务子目录里还挂着一套三年前的老系统早就没人维护也没人记得是谁装的。这种情况在老牌 CMS 上尤其普遍因为它当年部署门槛低随手一装就是一个站点后来业务迁移了站点还留着。资产清点要做到能回答四个问题有哪些实例在跑、分别是什么版本、部署在哪个网络位置、暴露到什么程度。前两个决定有没有已知问题后两个决定谁能碰到它。一个只在内部测试网段开放、且需要跳板才能访问的实例和一个直接对公网 80 端口开放的实例风险完全不是一个量级。实操上我建议用被动加主动两条腿走路。被动侧从网关日志、DNS 解析记录、证书透明日志里捞域名和 IP主动侧在授权范围内做指纹识别和目录探测。这里必须强调授权——任何主动探测都必须有书面授权范围和窗口期否则就是违规操作性质完全变了。企业内部的扫描也要走流程因为老系统本身很脆扫崩了业务是要担责的。2.2 版本识别与补丁状态的判断版本识别是判断风险的起点但不等于全部。老牌 CMS 的版本号通常会在几个位置暴露静态资源路径里的版本标识、页脚的版权信息、特定文件的哈希特征、以及接口返回里的字段。有些站点做了隐藏处理这时候就要靠文件指纹比对也就是把已知版本的若干静态文件算哈希跟目标比对。但我要提醒一个常见误区版本号新不代表没问题版本号旧也不代表一定有问题。因为这类系统的版本迭代里经常出现回退现象——某个修复在 A 版本上线在 B 版本分支合并时又被覆盖掉了。判断补丁状态更可靠的方式是直接看代码特征而不是看版本号。下面这张表是我在做老系统评估时常用的一页纸清单把风险维度拆开打分避免拍脑袋。评估维度判断依据高风险特征版本与分支静态指纹、文件哈希比对多年未更新、分支已停止维护网络暴露面端口与路径可达性公网直连、后台登录页对外开放默认配置残留安装目录、示例文件、默认账号安装入口未删、示例数据未清权限模型后台角色划分、文件操作权限单一管理员权限、全站可写运行环境Web 服务与解释器版本运行账号过高、目录可执行脚本内容来源是否允许外部用户投稿或留言匿名可写、审核环节缺失历史处置应急记录、日志留存无日志、无隔离、无备份这张表的价值不在于分数本身而在于它逼你把感觉有风险变成具体哪一条有风险。我一般会让负责的同学先把表填完再决定处置优先级。填表的过程中往往会自己发现一些问题比如某个实例的后台登录页居然是对公网开放的这个发现本身就比任何扫描报告都值钱。2.3 把可写和可执行两个属性彻底分开在老系统治理里我认为最值钱的一条原则是让可写的目录不可执行让可执行的目录不可写。这条原则听起来朴素但它能挡掉绝大多数从内容落地到代码执行的链路不针对任何一个具体缺陷通用性极强。具体怎么落地以常见的部署结构为例上传目录、缓存目录、附件目录这些必然要写入的位置在 Web 服务的配置里明确关掉脚本解析能力只允许返回静态内容。而程序代码目录则把运行账号的写权限收掉只保留读和执行。这两条做完即便某条链路成功让攻击者写入了一个文件这个文件大概率也跑不起来。我在实际操作中踩过的坑是只改了主站配置忘了虚拟目录或者别名路径也继承了同样的解析规则。结果主站防护到位通过一个二级路径别名绕了过去。所以配置改完之后一定要逐路径验证用不同的访问路径去测试同一个目录下的文件确认没有漏网的分支。这一步不能用应该生效了来交差。3. 防护侧的核心动作把攻击面收窄3.1 入口收敛是最便宜的高收益操作在成本有限的前提下我优先做的一定是入口收敛而不是去改代码。原因很实际改代码要回归测试、要走发布流程、可能引入新问题而入口收敛是配置层面的动作风险低、见效快、可回滚。入口收敛具体做三件事。第一后台入口不对公网开放。后台管理是整条链上价值最高的目标把它挪到内网、或者至少加一层访问控制直接砍掉一大块风险。第二安装和升级入口彻底删除。很多老系统的安装目录一直留着虽然通常有已安装的检测但这类检测逻辑本身也是代码历史上出过问题。最稳的做法就是物理删除。第三示例文件和数据清空。示例文件经常带有演示性的功能入口属于典型的开发者为了方便留下的后门。这里分享一个我自己的习惯接手任何一套老系统先花二十分钟把能删的都删掉再看好不好用。删掉之后如果业务报错说明业务依赖了不该依赖的东西这本身也是个应该被记录的问题。这个动作做完攻击面往往能缩小三分之一以上。3.2 输出编码比输入过滤更可靠关于 XSS 的防护行业里争论了很多年过滤还是编码。我的观点很明确输出编码是底线输入过滤是补充。原因是输入过滤面临黑名单永远不全的困境而且不同上下文的合法字符集不一样用一个统一的过滤规则去卡所有输入不是漏就是误伤。输出编码的正确做法是按上下文选择编码方式。内容进入 HTML 文本节点做 HTML 实体编码进入 HTML 属性除了实体编码还要确保引号处理正确进入 JavaScript 字符串要用 JS 转义而不是 HTML 转义进入 URL 参数要用 URL 编码。这四种上下文混用编码方式是常见错误比如把 JS 上下文当成 HTML 来转义看起来做了处理实际一点用没有。对于老系统现实的做法是在模板层做统一封装。把输出点收敛到几个封装的函数里在函数内部根据调用位置选择编码策略业务代码只调函数不直接拼接。这样即便有遗漏也能通过函数调用点的统计来做覆盖度检查比满代码找拼接点靠谱得多。注意模板引擎自带转义不等于万事大吉。很多老模板引擎的转义只覆盖默认输出语法一旦使用了原样输出的标记转义就失效了。审计时要把这类标记的使用位置全部列出来单独看。3.3 运行环境的最小权限这一块经常被忽略但它对getshell类结果的抑制效果非常直接。核心思路是假设代码一定会被打穿那么打穿之后能拿到什么。这就是纵深防御。具体做四件事。第一Web 服务的运行账号必须是专用的低权限账号不能是管理员也不能和数据库、缓存等其他服务共用。第二禁止该账号在系统临时目录、用户目录下执行脚本。第三数据库账号只授予业务必需的最小权限绝对不要用高权限账号连业务库更不要让业务库账号具备文件读写或命令执行类能力。第四配置好出站限制让被攻陷的主机难以横向或者外联。我见过最离谱的一次是某套系统的 Web 运行账号居然是超级管理员而且这台机器上还跑着其他三个业务。这种情况下任何一个入口被打穿影响都是灾难级的。后来整改就是把服务拆开、账号降权虽然过程麻烦但这是必须还的债。3.4 检测规则的设计思路规则这件事我不建议去堆砌现成的特征串。原因很直接针对具体载荷的特征串生命周期极短改个编码方式就绕过了。更稳的思路是盯着行为而不是盯着内容。值得监控的行为有几类后台高危功能在非常规时间被调用、单个账号短时间内大量访问不同管理页面、模板类文件或脚本文件出现内容变更、Web 目录下出现新增的可执行文件、异常的进程创建行为。这些行为的组合比任何单条特征都更能说明问题。因为这些动作在正常业务里极少发生一旦发生误报率低、处置价值高。落地的时候要注意基线问题。老系统的访问模式往往很固定先跑两周收集基线再设阈值比上来就配规则靠谱。我踩过的坑是一上来就设了很严的阈值结果业务做了一次批量数据导入直接告警刷屏值班同学直接把规则关掉了。规则一旦被关掉就很难再打开这个教训挺深刻。4. 代码审计的通用方法从数据流看问题4.1 危险函数的追踪路径做代码审计时我的习惯是先列危险函数清单再反查调用链。所谓危险函数指的是那些能触达文件系统、命令执行、模板解析、反序列化的能力点。清单不需要很长但必须完整覆盖语言本身的这类能力。列完之后做的是反向可达性分析从危险函数出发往上追参数来源看能不能追到外部输入。能追到的标为待确认追不到的暂时搁置。这个方法的好处是不依赖你事先知道漏洞长什么样纯靠数据流判断对新出现的缺陷类型同样有效。追的过程中要特别注意几类隐身的传递方式经过数组或对象包装后的传递、经过序列化再反序列化的传递、经过数据库或缓存中转的传递、以及通过全局变量或注册机制传递的。这几种情况在静态阅读时很容易断链但对攻击者来说是完全连通的。我一般会把这几类传递方式单独做标记重点跟。4.2 变量流向的记录方式人脑记不住复杂项目里的数据流必须借助工具或者手工记录。我习惯用一个简单的表格来跟每追一条链路就记一行入口参数名、经过的函数、做过的处理、最终落点。追到落点之后再看这个落点有没有做上下文适配的编码没有的话基本可以确认问题。举个抽象的例子来说明这套方法怎么用。某个参数从请求里取出来经过一次字符串拼接赋给一个模板变量模板里用原样输出的语法渲染。这条链路上没有任何一处做过编码落点是 HTML 上下文那么这就是一个典型的输出未编码问题。整个过程不需要记住具体函数名只需要记住取—拼—赋—渲染这四个动作。这种记录方式的另一个好处是可以做同类问题批量排查。当你在一个位置发现问题后把同样的四个动作在代码库里搜一遍往往能找到一批同样的写法。老系统的代码重复度极高一处有问题通常意味着一片都有问题。4.3 审计过程中容易走偏的地方第一个容易走偏的地方是只看入口不看上下文。看到有过滤函数就放心了但过滤函数是在什么上下文里用的如果参数最终进入的是 JS 上下文而过滤是按 HTML 上下文设计的那等于没过滤。上下文这个概念必须贯穿始终。第二个是忽略二次注入。数据第一次写入时经过了处理看起来是安全的但读出来二次使用的时候又被拼进了危险位置这时候原始处理就失效了。这类问题在老系统里非常常见因为数据经常在多个模块之间流转。第三个是低估配置类问题的危害。很多人审代码只审逻辑不看配置文件。实际上老系统的配置文件里经常有影响巨大的开关比如是否开启调试、是否记录详细错误、是否允许某种解析。调试模式开着报错信息里可能直接带出路径和参数这对攻击者来说是现成的信息源。5. 常见问题与应急处置速查5.1 怀疑被入侵后的处置顺序这一步顺序错了会很麻烦。我的建议顺序是先隔离、再取证、后清理、最后复盘。隔离指的是把受影响实例从网络上摘下来或者限制访问目的是止血防止影响扩大。这一步要果断不要因为先看看情况而拖延。取证指的是保存现场。具体要做的是对磁盘做镜像、导出关键日志、记录进程和网络连接状态。这里有个细节日志要先导出再清理很多同学着急清理把日志一起删了后面根本没法分析。另外要注意日志的时间基准多台机器的时区要统一否则拼不出时间线。清理阶段要做的是彻底清除。经验上只删掉发现的那个文件往往不够因为攻击者通常会留多个落点。稳妥的做法是比对文件完整性、检查计划任务和启动项、检查账号变更、检查数据库里的异常内容。清理完之后要验证验证的方式是从外部重新做一次检查而不是自己看一遍觉得干净了。复盘阶段最有价值的问题不是他是怎么进来的而是为什么这么久才发现。检测能力的缺口往往比漏洞本身更值得投入。5.2 高频问题速查表下面这张表是我整理的、在老系统安全治理里被问得最多的问题以及我给出的处理方向。现象或疑问常见原因处理方向后台登录页暴露在公网部署时未做网络隔离迁移到内网或加访问控制上传目录能直接访问脚本Web 服务未关闭该目录解析按目录配置解析策略并逐路径验证页面报错带出物理路径调试模式未关闭生产环境关闭详细报错错误统一落日志数据库账号权限过大部署时图省事用了高权限账号按业务重建最小权限账号日志缺失无法回溯未开启或未集中收集开启访问与错误日志并集中存储老系统无法升级业务强依赖定制改动先做隔离与加固同步规划替代方案打补丁后功能异常补丁与定制代码冲突建立定制点清单补丁前做影响评估扫描导致业务中断老系统对并发与异常输入不健壮扫描走窗口期限制速率先备后扫表格里的每一条我都至少遇到过一次。其中打补丁后功能异常是最容易让团队放弃治理的一条。我的经验是把定制改动做成清单每次升级前逐条核对把冲突点提前暴露出来。这个过程一开始很痛苦做两轮之后就顺了。5.3 迁移与替代的现实路径说句实在话对于已经停止维护多年的系统长期方案只有一个迁移。加固只能降低风险不能消除风险因为你看不到的那些代码路径永远可能存在未知问题。但迁移不是一拍脑袋就能做的尤其当系统上跑着核心业务的时候。我推荐的路径是先隔离、再并行、后切换。先通过入口收敛和网络隔离把风险压到可接受水平给迁移争取时间。然后新老并行把流量逐步导过去同时验证新系统的功能覆盖度。最后切换并保留老系统只读一段时间作为回退保障。这个过程中最容易出问题的是数据迁移的一致性。老系统往往有大量历史数据字段定义不规范迁移时容易丢或者错。我的做法是先做全量比对再做增量同步最后做抽样人工核验。抽样这一步不能省机器比对通过不代表业务上没问题很多逻辑上的错误只有人看得懂。6. 我在实际处置中的几点体会关于这类通杀型情报我最大的体会是恐慌的成本远高于漏洞本身。一条消息出来如果团队没有判断框架就会陷入全部系统都要排查的混乱资源被摊薄真正该优先处理的地方反而没人管。建立一个简单的评估框架——能不能被外部触达、需不需要前置权限、有没有可验证的公开信息——比任何扫描工具都管用。第二个体会是关于优先级。很多人第一反应是去修输入过滤我反而会先去做两件事把后台入口收起来把可写目录的执行权限关掉。这两件事加起来可能只需要半天但能挡掉整条链上最关键的两个环节。修过滤是个长期工程而这两件事是立刻见效的。安全工作的性价比判断很多时候就是看你能不能找到那个杠杆点。第三个体会是关于文档。我坚持每处置一次就留一份记录写清楚发现时间、影响范围、处置动作、遗留问题。这份记录的价值在当时看不出来但在半年后做同类评估、或者人员变动交接的时候价值巨大。老系统的知识最容易随着人员流失而蒸发文档是唯一的对抗手段。最后一个偏实操的小技巧给每套老系统建一个最小必要清单写清楚它到底需要哪些功能、哪些目录、哪些端口。清单之外的东西一律关掉。这个清单做起来很土就是一张纸的事但它能把这个能不能删这种反复纠结的问题一次性解决掉。我在几个项目里推行过这个方法效果比任何一次集中整治都持久因为它把决策前置了后面的人不需要重新判断一遍。 
长河君 · 2026/11/6 13:57:32 · 阅读 1.2k 老旧CMS的XSS与getshell风险防护及应急治理
项目中遇到过不少次类似的场面群里忽然冒出一条消息标题写得耸人听闻核心关键词是XSS、0day、通杀所有版本还带着一个可 getshell的尾巴配图往往是半个命令行窗口。消息传得飞快转发的人绝大多数并没有真的验证过只是觉得这事挺大。作为长期在甲方做安全建设和应急的人我对这类标题的第一反应从来不是赶紧下载试试而是三个问题它描述的缺陷类型是什么、影响面到底有多大、我手上的资产有没有暴露在同样的风险结构里。这三个问题才是有价值的而怎么打进去从来不是这篇文章要谈的内容。需要把话说在前面下面所有内容都围绕防护、检测、治理和应急展开不涉及任何利用代码、注入字符串、绕过手法或入侵步骤。原因很简单任何一篇公开的通杀型利用教程最终受益的都不是防守方。真正需要被讲清楚的是为什么一类老系统会反复出现同类问题、防守方如何快速判断自身暴露面、以及在无法立刻重写系统的现实约束下怎么把风险压下去。这篇文章适合三类人看负责企业资产安全的运维和安服同学、正在维护老项目的开发者、以及对 Web 安全刚入门、容易被这类标题带偏方向的学习者。1. 通杀所有版本这句话到底在说什么1.1 同一套代码骨架衍生出的共性缺陷一款内容管理系统会被说成通杀所有版本通常不是因为它每个版本都被单独挖出了洞而是因为它的代码骨架在多个版本之间几乎没变。老牌 CMS 有一个很典型的特征核心的模板解析、参数接收、文件写入这几条链路从早期版本一直沿用下来中间只做加法不做减法。新版本加功能、改界面、修某些具体报错但那几条老链路依然躺在那里甚至连函数名都没改过。这就导致一个结果只要某个位置存在输入未过滤、输出未编码的问题那么所有继承这套骨架的版本都会中招。攻击者不需要针对每个版本单独构造因为调用路径是一样的。所谓通杀本质上是同源代码的批量复用而不是什么高深的技术突破。理解这一点非常重要因为它直接决定了防守方的应对思路——你不需要去背某个具体版本的差异你需要判断的是这条代码链路在你的部署里是否存在、是否可达。我在实际审计中见过太多类似情况一个参数从入口传进来经过两三层函数调用最后被直接拼进了页面模板中间没有任何一处做过类型约束或字符过滤。这种链路的生命力极其顽强因为它能跑而且改动它可能影响大量正常业务于是每一任维护者都选择绕开而不是修掉。技术债就是这么积累成攻击面的。1.2 XSS 到 getshell 之间隔着什么标题里最容易让人恐慌的是可 getshell。这里需要把概念拆清楚否则很容易被带节奏。XSS 是浏览器端的问题它的作用域是访问者的页面上下文getshell 是服务器端的结果作用域是操作系统。两者之间并不是一步到位的关系中间必须存在某种把前端能力转化为后端能力的桥。常见的桥有三类我用生活化的方式解释。第一类是后台身份借用管理员的浏览器被脚本影响后攻击者可以以管理员身份去操作后台功能而后台里往往存在文件管理、模板编辑这类高危能力。第二类是存储型内容落地某些位置允许写入内容并被服务端当作代码执行典型的就是模板缓存目录。第三类是凭证或会话泄露通过在页面注入脚本获取到某些令牌再用这些令牌去调用更高权限的接口。看懂这个结构的意义在于防守方不需要等全链路打通才行动。这条链上有好几个断点可以掐掐住任何一个链条就断了。最常见也最有效的断点就是后台高危功能和可写目录的可执行性。很多人只盯着 XSS 的输入过滤其实那是性价比最低的一环因为过滤规则永远在被打补丁。1.3 为什么这类标题传播快但信息量低这类标题的传播逻辑和它的技术含量几乎无关。它踩中了几个心理点通杀意味着覆盖面广让人本能觉得自己的资产可能中招0day意味着没有补丁制造紧迫感getshell是结果导向比起存在反射型 XSS这种描述威慑力大得多。三条叠在一起转发是必然的。但从信息价值看这类描述几乎没有提供任何可行动的信息。它没说触发条件、没说前置权限、没说受影响的具体功能模块、没说部署环境要求。我曾经跟进过一次类似的舆情最后核实下来那条链路要求攻击者已经具备后台低权限账号而那个环境的默认配置根本不允许自助注册。也就是说对绝大多数实际部署来说风险是收敛的。提示看到任何通杀秒杀一键字样的安全情报先按这三条过滤——是否需要前置权限、是否依赖非默认配置、是否有可验证的公开编号。三条都过不了的优先级可以往后放。2. 老旧建站系统的风险画像怎么画2.1 先搞清楚自己的资产边界所有安全工作的第一步都是资产清点但这一步恰恰是很多团队做得最糊的。我见过不止一次出事后才发现某个业务子目录里还挂着一套三年前的老系统早就没人维护也没人记得是谁装的。这种情况在老牌 CMS 上尤其普遍因为它当年部署门槛低随手一装就是一个站点后来业务迁移了站点还留着。资产清点要做到能回答四个问题有哪些实例在跑、分别是什么版本、部署在哪个网络位置、暴露到什么程度。前两个决定有没有已知问题后两个决定谁能碰到它。一个只在内部测试网段开放、且需要跳板才能访问的实例和一个直接对公网 80 端口开放的实例风险完全不是一个量级。实操上我建议用被动加主动两条腿走路。被动侧从网关日志、DNS 解析记录、证书透明日志里捞域名和 IP主动侧在授权范围内做指纹识别和目录探测。这里必须强调授权——任何主动探测都必须有书面授权范围和窗口期否则就是违规操作性质完全变了。企业内部的扫描也要走流程因为老系统本身很脆扫崩了业务是要担责的。2.2 版本识别与补丁状态的判断版本识别是判断风险的起点但不等于全部。老牌 CMS 的版本号通常会在几个位置暴露静态资源路径里的版本标识、页脚的版权信息、特定文件的哈希特征、以及接口返回里的字段。有些站点做了隐藏处理这时候就要靠文件指纹比对也就是把已知版本的若干静态文件算哈希跟目标比对。但我要提醒一个常见误区版本号新不代表没问题版本号旧也不代表一定有问题。因为这类系统的版本迭代里经常出现回退现象——某个修复在 A 版本上线在 B 版本分支合并时又被覆盖掉了。判断补丁状态更可靠的方式是直接看代码特征而不是看版本号。下面这张表是我在做老系统评估时常用的一页纸清单把风险维度拆开打分避免拍脑袋。评估维度判断依据高风险特征版本与分支静态指纹、文件哈希比对多年未更新、分支已停止维护网络暴露面端口与路径可达性公网直连、后台登录页对外开放默认配置残留安装目录、示例文件、默认账号安装入口未删、示例数据未清权限模型后台角色划分、文件操作权限单一管理员权限、全站可写运行环境Web 服务与解释器版本运行账号过高、目录可执行脚本内容来源是否允许外部用户投稿或留言匿名可写、审核环节缺失历史处置应急记录、日志留存无日志、无隔离、无备份这张表的价值不在于分数本身而在于它逼你把感觉有风险变成具体哪一条有风险。我一般会让负责的同学先把表填完再决定处置优先级。填表的过程中往往会自己发现一些问题比如某个实例的后台登录页居然是对公网开放的这个发现本身就比任何扫描报告都值钱。2.3 把可写和可执行两个属性彻底分开在老系统治理里我认为最值钱的一条原则是让可写的目录不可执行让可执行的目录不可写。这条原则听起来朴素但它能挡掉绝大多数从内容落地到代码执行的链路不针对任何一个具体缺陷通用性极强。具体怎么落地以常见的部署结构为例上传目录、缓存目录、附件目录这些必然要写入的位置在 Web 服务的配置里明确关掉脚本解析能力只允许返回静态内容。而程序代码目录则把运行账号的写权限收掉只保留读和执行。这两条做完即便某条链路成功让攻击者写入了一个文件这个文件大概率也跑不起来。我在实际操作中踩过的坑是只改了主站配置忘了虚拟目录或者别名路径也继承了同样的解析规则。结果主站防护到位通过一个二级路径别名绕了过去。所以配置改完之后一定要逐路径验证用不同的访问路径去测试同一个目录下的文件确认没有漏网的分支。这一步不能用应该生效了来交差。3. 防护侧的核心动作把攻击面收窄3.1 入口收敛是最便宜的高收益操作在成本有限的前提下我优先做的一定是入口收敛而不是去改代码。原因很实际改代码要回归测试、要走发布流程、可能引入新问题而入口收敛是配置层面的动作风险低、见效快、可回滚。入口收敛具体做三件事。第一后台入口不对公网开放。后台管理是整条链上价值最高的目标把它挪到内网、或者至少加一层访问控制直接砍掉一大块风险。第二安装和升级入口彻底删除。很多老系统的安装目录一直留着虽然通常有已安装的检测但这类检测逻辑本身也是代码历史上出过问题。最稳的做法就是物理删除。第三示例文件和数据清空。示例文件经常带有演示性的功能入口属于典型的开发者为了方便留下的后门。这里分享一个我自己的习惯接手任何一套老系统先花二十分钟把能删的都删掉再看好不好用。删掉之后如果业务报错说明业务依赖了不该依赖的东西这本身也是个应该被记录的问题。这个动作做完攻击面往往能缩小三分之一以上。3.2 输出编码比输入过滤更可靠关于 XSS 的防护行业里争论了很多年过滤还是编码。我的观点很明确输出编码是底线输入过滤是补充。原因是输入过滤面临黑名单永远不全的困境而且不同上下文的合法字符集不一样用一个统一的过滤规则去卡所有输入不是漏就是误伤。输出编码的正确做法是按上下文选择编码方式。内容进入 HTML 文本节点做 HTML 实体编码进入 HTML 属性除了实体编码还要确保引号处理正确进入 JavaScript 字符串要用 JS 转义而不是 HTML 转义进入 URL 参数要用 URL 编码。这四种上下文混用编码方式是常见错误比如把 JS 上下文当成 HTML 来转义看起来做了处理实际一点用没有。对于老系统现实的做法是在模板层做统一封装。把输出点收敛到几个封装的函数里在函数内部根据调用位置选择编码策略业务代码只调函数不直接拼接。这样即便有遗漏也能通过函数调用点的统计来做覆盖度检查比满代码找拼接点靠谱得多。注意模板引擎自带转义不等于万事大吉。很多老模板引擎的转义只覆盖默认输出语法一旦使用了原样输出的标记转义就失效了。审计时要把这类标记的使用位置全部列出来单独看。3.3 运行环境的最小权限这一块经常被忽略但它对getshell类结果的抑制效果非常直接。核心思路是假设代码一定会被打穿那么打穿之后能拿到什么。这就是纵深防御。具体做四件事。第一Web 服务的运行账号必须是专用的低权限账号不能是管理员也不能和数据库、缓存等其他服务共用。第二禁止该账号在系统临时目录、用户目录下执行脚本。第三数据库账号只授予业务必需的最小权限绝对不要用高权限账号连业务库更不要让业务库账号具备文件读写或命令执行类能力。第四配置好出站限制让被攻陷的主机难以横向或者外联。我见过最离谱的一次是某套系统的 Web 运行账号居然是超级管理员而且这台机器上还跑着其他三个业务。这种情况下任何一个入口被打穿影响都是灾难级的。后来整改就是把服务拆开、账号降权虽然过程麻烦但这是必须还的债。3.4 检测规则的设计思路规则这件事我不建议去堆砌现成的特征串。原因很直接针对具体载荷的特征串生命周期极短改个编码方式就绕过了。更稳的思路是盯着行为而不是盯着内容。值得监控的行为有几类后台高危功能在非常规时间被调用、单个账号短时间内大量访问不同管理页面、模板类文件或脚本文件出现内容变更、Web 目录下出现新增的可执行文件、异常的进程创建行为。这些行为的组合比任何单条特征都更能说明问题。因为这些动作在正常业务里极少发生一旦发生误报率低、处置价值高。落地的时候要注意基线问题。老系统的访问模式往往很固定先跑两周收集基线再设阈值比上来就配规则靠谱。我踩过的坑是一上来就设了很严的阈值结果业务做了一次批量数据导入直接告警刷屏值班同学直接把规则关掉了。规则一旦被关掉就很难再打开这个教训挺深刻。4. 代码审计的通用方法从数据流看问题4.1 危险函数的追踪路径做代码审计时我的习惯是先列危险函数清单再反查调用链。所谓危险函数指的是那些能触达文件系统、命令执行、模板解析、反序列化的能力点。清单不需要很长但必须完整覆盖语言本身的这类能力。列完之后做的是反向可达性分析从危险函数出发往上追参数来源看能不能追到外部输入。能追到的标为待确认追不到的暂时搁置。这个方法的好处是不依赖你事先知道漏洞长什么样纯靠数据流判断对新出现的缺陷类型同样有效。追的过程中要特别注意几类隐身的传递方式经过数组或对象包装后的传递、经过序列化再反序列化的传递、经过数据库或缓存中转的传递、以及通过全局变量或注册机制传递的。这几种情况在静态阅读时很容易断链但对攻击者来说是完全连通的。我一般会把这几类传递方式单独做标记重点跟。4.2 变量流向的记录方式人脑记不住复杂项目里的数据流必须借助工具或者手工记录。我习惯用一个简单的表格来跟每追一条链路就记一行入口参数名、经过的函数、做过的处理、最终落点。追到落点之后再看这个落点有没有做上下文适配的编码没有的话基本可以确认问题。举个抽象的例子来说明这套方法怎么用。某个参数从请求里取出来经过一次字符串拼接赋给一个模板变量模板里用原样输出的语法渲染。这条链路上没有任何一处做过编码落点是 HTML 上下文那么这就是一个典型的输出未编码问题。整个过程不需要记住具体函数名只需要记住取—拼—赋—渲染这四个动作。这种记录方式的另一个好处是可以做同类问题批量排查。当你在一个位置发现问题后把同样的四个动作在代码库里搜一遍往往能找到一批同样的写法。老系统的代码重复度极高一处有问题通常意味着一片都有问题。4.3 审计过程中容易走偏的地方第一个容易走偏的地方是只看入口不看上下文。看到有过滤函数就放心了但过滤函数是在什么上下文里用的如果参数最终进入的是 JS 上下文而过滤是按 HTML 上下文设计的那等于没过滤。上下文这个概念必须贯穿始终。第二个是忽略二次注入。数据第一次写入时经过了处理看起来是安全的但读出来二次使用的时候又被拼进了危险位置这时候原始处理就失效了。这类问题在老系统里非常常见因为数据经常在多个模块之间流转。第三个是低估配置类问题的危害。很多人审代码只审逻辑不看配置文件。实际上老系统的配置文件里经常有影响巨大的开关比如是否开启调试、是否记录详细错误、是否允许某种解析。调试模式开着报错信息里可能直接带出路径和参数这对攻击者来说是现成的信息源。5. 常见问题与应急处置速查5.1 怀疑被入侵后的处置顺序这一步顺序错了会很麻烦。我的建议顺序是先隔离、再取证、后清理、最后复盘。隔离指的是把受影响实例从网络上摘下来或者限制访问目的是止血防止影响扩大。这一步要果断不要因为先看看情况而拖延。取证指的是保存现场。具体要做的是对磁盘做镜像、导出关键日志、记录进程和网络连接状态。这里有个细节日志要先导出再清理很多同学着急清理把日志一起删了后面根本没法分析。另外要注意日志的时间基准多台机器的时区要统一否则拼不出时间线。清理阶段要做的是彻底清除。经验上只删掉发现的那个文件往往不够因为攻击者通常会留多个落点。稳妥的做法是比对文件完整性、检查计划任务和启动项、检查账号变更、检查数据库里的异常内容。清理完之后要验证验证的方式是从外部重新做一次检查而不是自己看一遍觉得干净了。复盘阶段最有价值的问题不是他是怎么进来的而是为什么这么久才发现。检测能力的缺口往往比漏洞本身更值得投入。5.2 高频问题速查表下面这张表是我整理的、在老系统安全治理里被问得最多的问题以及我给出的处理方向。现象或疑问常见原因处理方向后台登录页暴露在公网部署时未做网络隔离迁移到内网或加访问控制上传目录能直接访问脚本Web 服务未关闭该目录解析按目录配置解析策略并逐路径验证页面报错带出物理路径调试模式未关闭生产环境关闭详细报错错误统一落日志数据库账号权限过大部署时图省事用了高权限账号按业务重建最小权限账号日志缺失无法回溯未开启或未集中收集开启访问与错误日志并集中存储老系统无法升级业务强依赖定制改动先做隔离与加固同步规划替代方案打补丁后功能异常补丁与定制代码冲突建立定制点清单补丁前做影响评估扫描导致业务中断老系统对并发与异常输入不健壮扫描走窗口期限制速率先备后扫表格里的每一条我都至少遇到过一次。其中打补丁后功能异常是最容易让团队放弃治理的一条。我的经验是把定制改动做成清单每次升级前逐条核对把冲突点提前暴露出来。这个过程一开始很痛苦做两轮之后就顺了。5.3 迁移与替代的现实路径说句实在话对于已经停止维护多年的系统长期方案只有一个迁移。加固只能降低风险不能消除风险因为你看不到的那些代码路径永远可能存在未知问题。但迁移不是一拍脑袋就能做的尤其当系统上跑着核心业务的时候。我推荐的路径是先隔离、再并行、后切换。先通过入口收敛和网络隔离把风险压到可接受水平给迁移争取时间。然后新老并行把流量逐步导过去同时验证新系统的功能覆盖度。最后切换并保留老系统只读一段时间作为回退保障。这个过程中最容易出问题的是数据迁移的一致性。老系统往往有大量历史数据字段定义不规范迁移时容易丢或者错。我的做法是先做全量比对再做增量同步最后做抽样人工核验。抽样这一步不能省机器比对通过不代表业务上没问题很多逻辑上的错误只有人看得懂。6. 我在实际处置中的几点体会关于这类通杀型情报我最大的体会是恐慌的成本远高于漏洞本身。一条消息出来如果团队没有判断框架就会陷入全部系统都要排查的混乱资源被摊薄真正该优先处理的地方反而没人管。建立一个简单的评估框架——能不能被外部触达、需不需要前置权限、有没有可验证的公开信息——比任何扫描工具都管用。第二个体会是关于优先级。很多人第一反应是去修输入过滤我反而会先去做两件事把后台入口收起来把可写目录的执行权限关掉。这两件事加起来可能只需要半天但能挡掉整条链上最关键的两个环节。修过滤是个长期工程而这两件事是立刻见效的。安全工作的性价比判断很多时候就是看你能不能找到那个杠杆点。第三个体会是关于文档。我坚持每处置一次就留一份记录写清楚发现时间、影响范围、处置动作、遗留问题。这份记录的价值在当时看不出来但在半年后做同类评估、或者人员变动交接的时候价值巨大。老系统的知识最容易随着人员流失而蒸发文档是唯一的对抗手段。最后一个偏实操的小技巧给每套老系统建一个最小必要清单写清楚它到底需要哪些功能、哪些目录、哪些端口。清单之外的东西一律关掉。这个清单做起来很土就是一张纸的事但它能把这个能不能删这种反复纠结的问题一次性解决掉。我在几个项目里推行过这个方法效果比任何一次集中整治都持久因为它把决策前置了后面的人不需要重新判断一遍。