One-line configuration to get the log4j2 nuclear vulnerability of Spring Boot project!

I believe that yesterday, many friends were busy looking through the epic loopholes in Log4j2, right?

I saw that there are still small partners in the group saying that the company has built a group of 800+ people to deal with...

Fortunately, mitigation measures and solutions were soon available. At the same time, log4j2 officially released the latest fix for the speed impact. Each application side can also implement a more stable repair plan.

However, I have seen various repair methods sent out in the group, which are really unsightly...so here is also how to repair the easiest for Spring Boot users.

The simplest way to repair

Some small partners actually thought of solving it directly through Spring Boot's Starter, so they also mentioned Issue to Spring Boot, hoping that spring-boot-starter-log4j2 can support the latest 2.15 version (when mentioning Issue, it is still rc1, which is now released )

But if you are familiar with the version mechanism of Spring Boot components, this does not actually need to be resolved by a special version. Just add a simple configuration, as shown in the figure below:

Yes, it's that simple, just configure it like the following pom.xml

<properties>
    <log4j2.version>2.15.0</log4j2.version>
</properties>

If you are learning Spring Boot, then I recommend a free tutorial that has serialized and updated for many years: 161bc276b36db9 http://blog.didispace.com/spring-boot-learning-2x/

postscript

I don't know if you have discovered that the last few vulnerabilities that have affected our Spring Boot applications are not original Spring Boot things.

For example: Log4j2 this time is not actually the log component used by Spring Boot by default. Spring Boot uses Logback by default. So the friends who did not change the log component this time all watched the excitement in the group yesterday. . .

Most of the more serious vulnerabilities before are caused by another third-party component. I believe you can guess who it is?

Yes, it is Fastjson.

Spring Boot's default JSON string serialization and deserialization tool is Jackson, not Fastjson. But I don’t know when it started, and the Fastjson solution became popular (I remember the XML configuration era began, maybe it is a performance consideration?).

Recently, DD still uses original components, so I haven't encountered these problems. It's quite comfortable. Therefore, in the end, it is recommended that if you do not encounter any special performance requirements or tasks that cannot be completed by other original components, you can use other solutions to replace the default solutions, which will be more stable. After all, in addition to the Spring official, the default scheme is also the most widely used in the entire ecosystem, and they can withstand the test.

Finally, under investigation, which Spring Boot default components do you usually replace? Tell everyone in the message area~

Welcome to pay attention to my official account: Program Ape DD, to share knowledge and thoughts that can’t be seen elsewhere