天呐！EL表达式注释绕过还能这么玩？我直接裂开！
兄弟姐妹们,今天咱们来聊聊一个让我又爱又恨的话题——EL表达式注释绕过，说真的，我第一次遇到这个玩意儿的时候，整个人都是懵的，心想这啥啊？怎么还有这种操作？但是等我真正搞懂之后，我直接惊了，原来Web安全还能这么玩！
事情的起因是这样的...
前两天我朋友在搞一个Java Web项目，突然跑来跟我说："卧槽，我写的过滤器怎么跟个摆设一样？"我一开始还没反应过来，结果他给我看了段代码，我当场就愣住了，那个过滤器里明明写了过滤EL表达式的规则，结果人家攻击者就加了一个注释符，直接把整个过滤机制给绕过去了！我当时那个心情啊，就跟吃了只苍蝇一样难受。
你们知道吗？EL表达式（Expression Language）在Java Web里那可是相当常用的，特别是配合JSP使用的时候，但是EL表达式注释绕过这个漏洞，就像是给攻击者留了一扇后门，他们只需要在表达式里加上特定的注释符号，就能让我们的过滤规则瞬间失效。
这个漏洞到底咋回事？
听完我朋友的事儿,我赶紧去查了查资料，这才明白过来，原来在EL表达式中，和是最常见的两种语法，而我们平时写的过滤规则，一般就是过滤这两个符号对不对？重点来了，攻击者完全可以在这些符号中间插入注释符，、甚至是一些HTML注释。
我举个例子啊,咱们本来要过滤${param.x}这个表达式，结果攻击者写成${/*test*/param.x}，你们猜怎么着？很多新手写的过滤器直接就漏过去了！我当时看到这个案例的时候，真的是倒吸一口凉气，这也太鸡贼了吧！
更绝的是,有些EL表达式解析器还支持Unicode编码的注释，比如\u002f\u002f这种，就是双斜杠的Unicode编码，你说这谁能顶得住啊？我反正是服了，这简直是道高一尺魔高一丈的真实写照！
为什么我会这么在意这个？
其实吧,我做安全也好几年了，见过不少奇葩漏洞，但是这个EL表达式注释绕过真的是让我印象深刻，不少开发者在写安全防护的时候，都抱着"我过滤了关键字就万事大吉"的心态，结果就是被各种绕过姿势打得满地找牙。
我跟你们说,这种注释绕过不仅仅存在于EL表达式中，在SQL注入、XSS攻击中也经常出现，所以啊，大家在写防护代码的时候，一定要多留个心眼，别以为加个简单的过滤规则就高枕无忧了，不然真的会像我朋友那样，被人钻了空子还不知道咋回事儿。
我们要怎么防护呢？
说到这个,我可得好好给大家支几招，首先啊，别用那些简单的字符串匹配去过滤EL表达式，那玩意儿跟纸糊的没啥区别，我们要做的是解析整个表达式树，把所有的注释都剥离掉，然后再进行安全检查。
建议大家在web.xml里面配置全局的安全过滤器，而且要对所有参数进行统一编码处理，这样能大大降低被绕过的风险，还有就是，如果项目允许的话，直接用较新版本的EL表达式实现，因为新版本在解析的时候对注释的处理会更加严格。
反正我现在看到哪些还在用老一套过滤方式的代码,我就忍不住想吐槽：兄弟，你这是拿命在测试啊！
总而言之呢,EL表达式注释绕过这个问题真的是不容小觑，希望大家看完这篇文章能有所收获，咱们做安全的，不能总指望攻击者按套路出牌，对吧？我反正现在看到注释符号就条件反射地想到安全性问题，哈哈！
行了,今天就唠到这儿吧，如果你们也对网络安全感兴趣，想学习更多相关知识，或者有什么疑问想和我交流的，欢迎随时加QQ聊聊：2811972725，咱们下期再见啦！记得点赞转发哦，让更多的小伙伴看到这个坑！
本文为网络安全技术知识分享，仅为学习研究使用，请勿用于非法用途。
