Posted on

How To Detect and Secure Your Java App From Log4j Vulnerabilities

Apache Log4j is the popular open source logging library for Java developers that was recently caught up in a massive security-related breach. Due to its popularity, a large number of organizations were affected by the breach. For the latest news, refer to the official website about specific issues and patches. Here is an additional article that explains the core issues in detail.

List of Security Issues That Were Found in Log4j Version 2.x:

  1. CVE-2017-5645: Apache Log4j socket receiver deserialization vulnerability  (Severity - Moderate)
  2. CVE-2020-9488: Improper validation of certificate with host mismatch in Apache Log4j SMTP appender (Severity - Low)
  3. CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker-controlled LDAP and other JNDI-related endpoints (Severity - Critical)
  4. CVE-2021-45046: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations (Severity - Critical)
  5. CVE-2021-45105: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation (Severity - Critical)
  6. CVE-2021-44832: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration (Severity - Moderate)

4 Ways To Secure Your Java Application:

1.  Detect if You Have Log4j 2.x in Your Code Base 

Apache Log4j can be in your project directly or a dependency of a dependency. Thus, it's best to use a build tool such as Maven or Gradle to quickly scan for the same tree as follows:

Posted on

Getting Started With Jakarta EE 9: Hello World

Introduction

The release of Jakarta EE 9, at the end of 2020, was in many ways a historic event. The Java Enterprise framework is already 20 years old, having its first release in 1999. It has changed names a few times but the main concepts of the first release can still be found in this new release. During all those years, it has adapted itself to keep it up to date but has always adhered to its main principle of stability and backward compatibility.

Regarding backward compatibility, this release was also historic as the namespaces changed (like package names that changed from 'javax' to 'jakarta'). The change is straightforward, no other changes are introduced between Jakarta EE 8 and EE 9.  This to make the migration as easy as possible.

Posted on

MicroProfile: Your Cloud-Native Companion for Enterprise Java [Video]

Writing microservices within Jakarta EE is technically possible, but you miss a few goodies for the distributed environment you are running in.

MicroProfile wants to optimize your enterprise Java application by creating Java standards that link to some well-known cloud-native standards like etcd for configuration, OpenTracing and Jaeger for distributed tracing, and Prometheus for metrics.

Posted on

Getting Started With Jakarta EE 9

Jakarta EE 9 has officially been released on 22 November 2020 making it the first official release from Eclipse Foundation that completely moved away from the Oracle copywritten Java EE namespace.

So what can we look forward to with this release?

Posted on

Understanding Jakarta EE 8 CDI (Part 2): Qualifying Your Beans

enter image description here[As we continue with this series, we will refer to some content and examples from the CDI 2.x specification].

In order for the CDI container to recognize your bean for injection, your bean needs to be qualified. This can be achieved by associating a bean with a qualifier type. A qualifier type represents some client-visible semantic associated with a type that is satisfied by some implementations of the type (and not by others). In other words, a qualifier type identifies a bean with a type that can be satisfied to one specific implementation of the same type (else it becomes an unsatisfied dependency).

Posted on

Top 40 Questions for a Spring Framework Interview

The Spring framework makes J2EE (Java 2 Platform Enterprise Edition) development easier and is used to create testable, high performing, reusable code. Spring is commonly applied in the information technologies and financial sector due to its modularity and dependency injection features.

Financial technology is an exciting and evolving field for developers who want to work at companies like MIT, Accenture, or Visa, which prefer Spring over Java EE. These companies are looking for developers like you with Spring Framework experience to help digitize their enterprise needs.

Posted on

Help Inform Azure Java EE Migration Guides

The Azure team at Microsoft (myself included) has been strengthening its commitment and outreach to the Java EE community and customers. A few months ago, I ran a study with the community and customers to understand how Java EE developers move to the cloud. One of the interesting findings of the study is that Java EE developers like to see migration guides that speak to their use case from cloud providers like Microsoft. Following up on these findings, the team is now developing just such guidance that hopefully speaks to you, starting with Linux virtual machines and Kubernetes.

The idea is to target Azure migration of major Java EE application server workloads (such as WebSphere ND, WebSphere Liberty, WebLogic, JBoss EAP, and WildFly). The guidance will likely include online documentation, ARM templates, Azure Marketplace solutions, Docker images, Helm charts, samples, workshops, talks, and so on. All the materials will be developed completely in open source so customers and the community can contribute at any point.

Posted on

Getting Started With Java EE 8, Java 11, and Eclipse for Enterprise Java and Wildfly 16

If you have been in the Java EE space over the last few years, Eclipse IDE for Java Enterprise Developersis probably one of the best IDE experiences, making the creation of applications with important EE components like CDI, EJB, JPA mappings, configuration files, and good interaction with some of the important application servers (TomEE, WebLogic, Payara, Wildfly, JBoss).

In this line, Red Hat develops the Eclipse variant "CodeReady Studio," providing you with an IDE that supports Java Enterprise frameworks, Maven, HTML 5, Red Hat Fuse, and OpenShift deployments.

Posted on

Jakarta EE Without javax: The World Won’t End This Time Either

If you missed the news back in 2017, Oracle is donating the Java EE specification to the Eclipse foundation. This decision has followed a rather long period of hibernation in the specification process where people rightfully suspected a loss of strategic interest in Java EE by Oracle. At first, the decision to donate the specification was well-met by the Java EE and broader Java community. Without Oracle slowing down the process, those involved in Java EE could once again attempt to close up to non-standardized APIs. Until today, the donation process was, however, incomplete due to Oracle and the Eclipse Foundation being in disagreement about several details of the donation being made.

While turning over all intellectual property, Oracle was less generous when it comes to the use of its Java brand within the specification’s new home. Java EE does, of course, contain the name of the open-source, yet trademark-protected platform that is owned by Oracle. And this renders a problem in a legal context: If you grant a third party the use of your brand's name, you have yielded rights to restrict it in the future. To make things worse, you are potentially weakening your position in court when it comes to lawsuits regarding your brand. With the history of Oracle and Google arguing about Java licensing for years, one could, therefore, have anticipated that branding would be a difficult discussion point. And without pretending to know much about international trademark law, I was told by people more involved that "use it or lose it" is a good enough approximation for understanding the general motto of such disagreements. As a first result, the specification was therefore renamed from Java EE to Jakarta EE to avoid a clash of interests.

Posted on

Hot-Deploying Java Enterprise With WAD and Docker [Video]

I’ve recorded a video on how to minimize the development turnaround times with Watch and Deploy (WAD) by Adam Bien and Docker containers. The WAD tool watches for file changes and will re-build and re-deploy our applications to an auto-deployment directory. We’ll see how that approach can be integrated into containers that are created by the same Docker images that run in production.

Besides the news around the fast turnaround with Quarkus, which is a very interesting project, it’s possible to have a good development experience solely with Java EE and application servers that deploy quickly. The WAD tool watches for any changes that we make in the project and re-deploys our applications. If you run your application in Docker containers, you can and, in fact, should use the same Docker image locally that you will later run in production.

Posted on

Thoughts on Quarkus

Quarkus, the new “supersonic, subatomic” Java framework is currently getting a lot of attention. The ideas behind this build and runtime tool are indeed more than interesting for the future of enterprise Java. What are the benefits and shortcomings of using Quarkus? Let's find out.

Getting Rid of Dynamics

Quarkus takes the reasoning that most of the dynamics of an enterprise Java runtime is not really required in a containerized world. Once you build your application to a container image, the functionality is usually not supposed to change. All of the dynamics that an enterprise container brings allows for very powerful and flexible programming and deployment models, but once our applications have been started inside containers, they typically don’t change anymore.