apache log4j2漏洞修复 个人亲测解决

       换句话说假如开发设计在log4j的xml文件系统变量里配备的这类更换是没有危害的，即使你关掉了lookup也依旧能确保更换一切正常。可是假如你的开发人员的开发设计习惯是在输入输出的情况下立即拼凑语句例如log.error("${sys:java.version}"+"xxxxx")，那样此刻关掉了lookup会导致打印不出来javaversion反而是原状打印。那假如开发人员确实这样干了随后咱们关掉了lookup这会导致什么问题呢？

轻度的也许会导致后面打印的排错系统日志不具有排错使用价值，导致没法排障。假如你的报警解析使用了lookup之后的值，那样很可能出故障了报警也不会响，假如你的系统日志传递给中下游程序流程做解析，那样这一系统日志和预估不同也许导致中下游解析出差错，因而，咱们不能盲目跟风的关掉lookup，终究谁也不知道你的程序员、GitHub的程序员她们到底是怎么写代码的。最少要清楚有这类不确定性的安全风险在开展风险分析后发布修补。

（2）系统系统变量

咱们看见最初的修补方案里有3个等效的对策：

jvm参数-Dlog4j2.formatMsgNoLookups=true

在app的classpath下加上log4j2.component.properties系统变量文件，文件信息：log4j2.formatMsgNoLookups=True

设定系统系统变量FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS设定为true

这3个是等效的，换句话说设定在其中1个就可以了，理想化上我偏重于发布系统系统变量，由于这一非常简单，运维管理可以立即发布，并且是全局性的，自然别的也是可以的。但事实上呢？有下边2个问题：

这3个在2.10下列均处在失效状态，假如你第一时间发布了这3个那样你需要注意点

系统系统变量这一key值是不正确的，某司再次公告把它除掉了

但事实上呢，假如你刚开始只接推了第一版修补方案的系统系统变量，那样祝贺你了，你的工作是没用的，各种各样实际意义上。通过测试后咱们发觉系统系统变量换为这一值才是起效的LOG4J_log4j2_formatMsgNoLookups=True。