HQL injection trough orderBy

[CSIRTTrizna]

Observed vs. expected behavior

When using JPAQuery.orderBy with user provided input there is a possibility to inject HQL query, which is then executed in database.

Steps to reproduce

Full POC code is available in repository:
https://github.com/CSIRTTrizna/CVE-2024-49203/

1. Create JPAQuery object instance:

JPAQuery<Test> query = new JPAQuery<Test>(entityManager).from(test);

2. Create OrderSpecifier object instance:

PathBuilder<Test> pathBuilder = new PathBuilder<>(Test.class, "test");
OrderSpecifier order = new OrderSpecifier(Order.ASC, pathBuilder.get(orderBy));

Where orderBy variable is user provided input.

3. order and run the query

JPAQuery<Test> orderedQuery = query.orderBy(order);
orderedQuery.fetch();

Environment

Library versions used in proof of concept to reproduce the vulnerability:

querydsl-jpa: 5.1.0
querydsl-apt: 5.1.0
hibernate-core: 6.1.1.Final
jakarta.persistence-api: 3.1.0
postgresql: 42.7.4

Querydsl version: 5.1.0

Querydsl module: querydsl-jpa

Database: postgresql

JDK: 23

Additional details

Article detailing the vulnerability : https://www.csirt.sk/querydsl-java-library-vulnerability-permits-sql-hql-injection.html

[romanhuba]

This can be easily fixed by using one of the provided PathBuilderValidator's when a path is being built from user input.

For example:

PathBuilder<Test> pathBuilder = new PathBuilder<>(Test.class, "test", PathBuilderValidator.FIELDS);

The default validator returns the property without any validation, which makes it unsuitable for this use case.

From http://querydsl.com/static/querydsl/3.6.0/reference/html/ch03.html 3.1.3. Dynamic paths:

PathBuilderValidator.FIELDS will verify field existence, PathBuilderValidator.PROPERTIES validates Bean properties and JPAPathBuilderValidator validates using a JPA metamodel.

[CSIRTTrizna]

Hello,
Thank you for your comment.
You are right, that fixed the issue. However, I don't understand why the default setting is deliberately insecure. Is there any reason why the FIELDS validator is not enabled by default? In my opinion, it would likely be much more secure if the validator was enabled by default, and only disabled in specific edge cases when necessary.

[romanhuba]

Having the functionality enabled by default would certainly make it safer, but using other validators implies some computational overhead, which could be significant in cases where this construct is used extensively. I would guess that the authors of this library did not intend for the path builder to be used with unverified user input, and this should definitely be better documented. Having no validator could make sense when the developer is the one providing the property names.

[CSIRTTrizna]

Yes, I get your point. I guess the ideal solution would be to add a visible warning in the documentation stating that, by default, the PathBuilder is unsafe and allows any HQL/SQL code execution, and that it should be used with caution.

[CSIRTTrizna]

I am conflicted, whether to close this issue or leave it open so that it can serve as a warning for developers in the future.

[romanhuba]

A more useful outcome would be updating the documentation and Javadoc for the relevant components.

[CSIRTTrizna]

Perhaps yes. However, I still think it would make more sense to have the default setting check the columns. There shouldn't be much overhead, as the columns should be defined in the Entity class, making the lookup complexity something like O(1).

[koisurunippon]

Hi, is there a release plan for a new querydsl version that fixes this issue? Thanks.

[CSIRTTrizna]

Hi, from what I’ve observed, this repository is more or less inactive. I would recommend switching to the new fork of QueryDSL from OpenFeign (https://github.com/OpenFeign/querydsl). Although they face the same issue, the authors are actively communicating with me and working to resolve the problem as quickly as possible.

[koisurunippon]

Thanks CSIRTTrizna

[DengChen2020]

I think the problem mainly lies in the fact that you allow users to input, and you should validate their input. It's not a bug that orderBy might be an expression. It's appropriate not to validate the default case.

[CSIRTTrizna]

So, do you think it is appropriate for a framework that calls itself safe to have unsafe / insecure default settings in the common use of essential query functionality?