表达式注入值得吗？聊聊我踩过的那些坑
哎呀,今天突然想聊一个话题——表达式注入值得吗？说实话，这问题我刚入行那会儿压根没想过，后来做安全测试的时候被它折腾得够呛，才慢慢有了点自己的体会，你要是也在纠结这事儿，不妨听我絮叨絮叨。
先说说什么叫表达式注入
别嫌我啰嗦啊,还是得简单交代一下背景，表达式注入（Expression Injection）这玩意儿，说白了就是攻击者把你程序里本来该老老实实计算的表达式给“劫持”了，塞进去一些他自己想执行的东西，最常见的就是 SpEL（Spring Expression Language）、OGNL、EL 这些，你以为用户输入的是个简单的数学公式，结果人家直接给你来个 Runtime.exec()，服务器就被人拿下了……想想都后背发凉。
我第一次碰到这玩意儿的时候,是在一个老项目里，当时还傻乎乎地想：“不就是个表达式嘛，能有啥大问题？”结果漏洞报告一出来，CVE 都给我安排上了，那一刻我才明白——表达式注入值得吗？从安全角度看，真的太不值了！
为什么总有人“明知故犯”？
你可能会问,既然这么危险，为啥还有那么多框架、那么多代码里在用？哎，这事儿吧，得两边看。
表达式确实好用啊！动态计算、灵活配置、少写一堆 if-else，开发效率嗖嗖往上涨，我承认，我自己也曾经为了图省事，在项目里直接 parseExpression 用户传进来的字符串，当时觉得“内网系统嘛，没事儿”，现在回想起来，真想抽自己两下。
很多开发者压根没意识到这是“注入”，他们觉得 SQL 注入我防了，XSS 我转了，命令注入我过滤了，表达式？那不就是个计算器吗？嘿，恰恰就是这个“计算器”，能让你整个应用原地升天。
表达式注入值得吗？我的答案是……
如果你问我“表达式注入值得吗”，我得先反问一句：你说的“值得”是指哪方面？
如果是从攻击者视角——那当然“值得”啊！一个表达式注入漏洞，往往等于远程代码执行（RCE），危害等级直接拉满，比起辛辛苦苦找 SQL 注入、绕 WAF、慢慢提权，表达式注入有时候一个 payload 就搞定了，省时省力，性价比“极高”。（我是站在防御方说的，别误会！）
但如果是从开发者、从企业安全视角——那绝对不值得！你省下来的那点开发时间，最后可能要用几倍的应急响应、数据泄露赔偿、品牌损失来还，我见过太多团队，因为一个 SpEL 注入，连夜加班打补丁、写报告、安抚客户，那个悔啊，真是“早知如此，何必当初”。
那到底该怎么防？
别急,我不是那种只抛问题不给方案的人，结合我自己的经验，几个实用的建议：
- 能不用就不用——如果业务逻辑不需要动态表达式，千万别为了“看起来高级”硬上。
- 别让用户直接控制表达式——哪怕非要动态，也做成白名单映射，比如用户只能选 A、B、C 三种计算方式，而不是直接传字符串。
- 用 SimpleEvaluationContext——Spring 里有个
SimpleEvaluationContext，功能受限但安全得多，能不碰StandardEvaluationContext就别碰。 - 输入过滤 + 沙箱——虽然不能百分百防住，但能挡住大部分低级 payload。
- 安全测试别偷懒——SAST、DAST、IAST 都跑起来，尤其是用了表达式解析的地方，重点关照。
最后说点掏心窝子的话
写了这么多,其实就想表达一个意思：表达式注入值得吗？从长远看，真的不值得，别为了一时的方便，埋下一颗随时会炸的雷，我当年踩过的坑，不希望你再踩一遍。
安全这事儿吧,平时觉得是负担，出事的时候才知道是救命稻草，表达式注入只是众多注入类型里的一种，但它带来的危害，绝对排得进前三，所以啊，下次你写代码的时候，看到 ExpressionParser 或者 Ognl.getValue，手停一下，想一想——这玩意儿，真的非用不可吗？
行了,今天就唠到这儿，如果你也有类似的经历或者想法，欢迎一起交流，安全路上，咱们互相提醒，少踩坑，多睡觉，晚安啦！