Log4J 中存在严重的安全缺陷，显然已被修补。但我还没有找到一个可以理解的解释来说明日志框架中如何存在安全缺陷。
这似乎与“查找”有关。 https://logging.apache.org/log4j/2.x/manual/lookups.html
但这是在配置文件中，而不是可以注入的日志文件中？
问题。我如何一劳永逸地消灭所有聪明的东西以防止将来出现任何漏洞？我只想记录。
闻起来好像我需要删除任何“$”符号，但这只是一个猜测。（还应该删除任何 \ns 以避免日志文件欺骗。我总是为日志记录编写一个非常简单的包装器，以便能够执行此类操作。）
（我有一个非常简单的垫片，所有日志消息都会经过，因此我很容易删除所有不在格式字符串中的“$”。）
防止查找引起的漏洞的唯一方法是完全禁用它们。
\n根据 log4j2 团队的说法，实现这一点的方法是附加 Java 参数
\n-Dlog4j2.formatMsgNoLookups=true
这肯定修复了通过将 ${...} 序列放入用户输入中（如记录的 URL 中）来调用查找的能力。
\n不幸的是，即使您使用参数或记录异常堆栈跟踪，查找也会应用于记录的序列。代码中的查找序列并不危险，因为它们是可控的。但来自用户的那些是不可预测的。如果您记录“错误的用户名：xxx”，您将不知道用户可以输入什么来利用另一个漏洞。
\n但是，您无法确定框架中是否存在其他严重错误，因此切换到其他日志记录框架是合理的。
\nLogback是一个很好的候选者，它是由 Log4j 的原作者发起的。开发者明确表示，他的框架与 Log4j2 中引入的安全问题无关：
\n\n\n除非另有说明，否则当我们说 log4j 时，我们指的是 log4j 1.x。我们还应该强调，logback 与 log4j 2.x 无关。\n它不与 log4j 2.x 共享代码或漏洞。
\n
该错误显然在 2.16.0 版本中得到了修复，但它仅解决了该特定漏洞，并且危险的查找功能并未被删除。
\n根据Sophos 报告，
\n\n\nLog4j 的更新版本仍然支持字符串 \xe2\x80\x9clookups\xe2\x80\x9d 的潜在危险\n所见即所得系统，但是\n基于网络的 JNDI 连接，无论是在同一台计算机上还是\n连接到其他地方，默认情况下都不再启用。
\n
换句话说，log4j2 仍然不安全，但不像以前那么不安全。
\n| 归档时间： |
|
| 查看次数： |
1313 次 |
| 最近记录： |