常见框架漏洞

2021年12月，框架Log4j2爆出JNDI注入漏洞，漏洞全球数百万台服务器一夜之间暴露在远程代码执行的框架风险下。这个漏洞本身不复杂——Log4j2在打印日志时，漏洞如果遇到${ jndi:ldap://...}这样的框架字符串，会乖乖去加载远程类文件。漏洞攻击者只需要在用户可控的框架输入框里填上这段payload，服务器就可能被拿下。漏洞问题出在框架的框架"便利性"设计上：日志打印本该是只读操作，却内置了表达式解析和远程加载能力。漏洞这种"贴心"最终变成了灾难。框架

框架漏洞有个共同特征：它们往往不是漏洞代码写错了，而是框架设计取舍在特定场景下失控。Spring框架的漏洞SpEL表达式注入就是典型。SpEL允许在运行时动态求值，框架开发者用它做灵活配置，但如果用户输入被直接拼进SpEL表达式，攻击者就能通过T(java.lang.Runtime).getRuntime().exec(...)执行任意命令。2022年Spring Cloud Gateway的CVE-2022-22947就是这个路子——Actuator端点未授权访问，配合SpEL注入，直接RCE。这类漏洞的修复通常不是打补丁那么简单，而是要在框架层面限制表达式的求值范围，或者干脆禁掉危险函数。

Struts2的漏洞史更像一部连续剧。从2010年的S2-005到2017年的S2-045，几乎每年都有新的OGNL表达式注入。OGNL本身是Object-Graph Navigation Language，用来在Java对象图上导航取值。Struts2把它暴露在了HTTP参数解析环节，攻击者通过%{ ...}就能注入OGNL表达式。S2-045那个漏洞尤其讽刺：Content-Type头里的multipart/form-data解析出错时，错误信息会直接把用户输入拼进OGNL表达式。一个本该只处理文件上传的组件，因为异常处理不当，变成了远程命令执行入口。

前端框架也不是净土。React在服务端渲染时，如果直接使用dangerouslySetInnerHTML且未做转义，XSS就来了。Vue的模板编译在特定版本下也存在沙箱逃逸问题——攻击者通过构造特殊的模板表达式，可以突破Vue的沙箱限制访问全局对象。2020年Vue 2.x的CVE-2020-7608就是这类问题：v-bind指令在特定条件下可以被绕过，执行任意JavaScript。前端框架的漏洞利用门槛更低，因为攻击者只需要诱导用户点击一个链接。

框架漏洞的根源通常不在框架本身，而在使用方式。开发者习惯性地信任框架的默认配置，把用户输入直接交给框架处理，忽略了框架文档里那些"危险"警告。Log4j2的JNDI功能默认开启，Spring的Actuator端点默认暴露，Struts2的OGNL解析默认启用——这些默认值在开发环境里方便，在生产环境里就是定时炸弹。我见过一个内部系统，用了五年前的Struts2版本，问为什么不升级，答曰"业务代码太老，升级怕出问题"。结果被扫描器扫到S2-045，连夜加班打补丁。

修复框架漏洞没有银弹。升级版本是最直接的，但往往牵扯依赖冲突和兼容性问题。临时缓解措施比如WAF规则、禁用特定功能、限制网络访问，能争取时间但不能根治。真正有效的做法是在架构层面做隔离：把处理用户输入的组件和执行业务逻辑的组件分开，限制框架的反射和动态加载能力，对表达式求值做白名单。这些措施会增加开发成本，但比起被入侵后的损失，这笔账不难算。

框架漏洞不会消失。只要框架还在追求"灵活"和"便利"，就必然会在某些地方打开攻击面。开发者的任务不是找到一劳永逸的解决方案，而是保持警惕——关注安全公告，理解框架的底层机制，对用户输入保持不信任。那个Log4j2的夜晚，很多团队通宵未眠，但真正该问的是：为什么一个日志库需要远程加载类文件的能力？这个问题，比漏洞本身更值得思考。

本文地址：http://www.79wt.cn/news/1661f1699817.html