Skip to content

Don't Panic! Posts

JPA native queries with eager fetch and @SqlResultMapping

JPA supports eager and lazy fetch of child entities. If you’re not careful with the lazy fetch strategy it can result in excessive queries as it needs to execute a query for the parent entity and then an additional one for each child. This is the so-called n+1 problem. You’ll often want to use eager fetching so that you can pull the parent and all children with a single query.

If you use HQL/JPQL, the JPA Criteria API or queries derived from Spring Data Repository method names, JPA will convert your SQL query result set to entity objects. That’s what an Object Relational Mapping (ORM) system is for. However if you use JPA native queries (SQL), you’ll need to map the results yourself.

In this post, I’ll look at how to run eager fetches for JPQL and native queries and how to manage the results.

CVE-2023-34034: Spring Security Authorization Bypass

CVE-2023-34034 is another authorization bypass in Spring Security. Like CVE-2022-31692 it’s nasty because it allows completely unrestricted access to supposedly protected resources. Also like CVE-2022-31692 it requires very specific configuration to be vulnerable and is easily fixed.

This post demonstrates the vulnerability, the problem configuration and suggested fixes. A demonstration vulnerable application is on GitHub.

CVE-2022-42889 Text4Shell vulnerability in Apache Commons Text

CVE-2022-42889 Text4Shell is a vulnerability in the Apache Commons Text library. Like previous brand-name vulnerabilities Log4Shell and Spring4Shell, it’s a Remote Code Execution (RCE) vulnerability that allows a bad actor to run arbitrary code on the host machine. However it’s less likely to be exploitable as it requires a very specific use of the library to be vulnerable.

It affects Apache Commons Text 1.5 to 1.9 and was fixed in 1.10. However, as we’ll see later the application code can still be vulnerable to other attacks even in the fixed version.

Testing System.exit()

Using JUnit for testing System.exit() calls from application code can be tricky. This is because System.exit() terminates the JVM running it. If you’re running JUnit, this is the JUnit runner. If JUnit invokes System.exit() in application code it will end your test without deciding a success / fail status and will also terminate the test run.