JPQL中可引发SQL注入的orderBy参数值及危害分析

针对你给出的JPQL拼接代码：

String orderBy = getParameter("orderBy");
String orderDir = getOrderDir(); // returns "asc" or "desc"
String query = "select u from User u order by u." + orderBy + " " + orderDir;

虽然JPQL不支持union或注释注入，但这种直接拼接的写法依然存在可被利用的实际风险，并非只会触发查询异常：

• 敏感数据盲注泄露
  可以构造排序条件来推断敏感字段的内容，比如传入case when u.password like 'a%' then 1 else 0 end作为orderBy参数。执行查询后，观察结果的排序顺序：如果以desc排序时，密码以a开头的用户排在前面，就可以逐步暴力破解密码的每一位。这种方式属于布尔盲注，不需要直接获取字段值，仅通过排序结果就能窃取敏感数据。

• 拒绝服务（DoS）攻击
  构造包含复杂聚合或关联逻辑的排序表达式，比如传入(select count(*) from User u1 join User u2 on u1.id=u2.id join User u3 on u2.id=u3.id)。这类表达式会让数据库执行大量的关联计算，占用CPU、内存等资源，导致查询耗时剧增，甚至拖垮整个数据库服务，影响系统可用性。

• 绕过字段访问限制
  如果系统原本只允许用户按公开字段（如username、createTime）排序，攻击者可以通过注入未授权的敏感字段（如u.password、u.email）进行排序。虽然不会直接展示字段内容，但可以通过排序结果推断字段的特征，比如按length(u.password) desc排序后，能知道哪些用户的密码更长，结合其他信息进一步攻击。

总的来说，这种漏洞的危险程度属于中高危：虽然无法直接执行任意SQL破坏数据，但数据泄露和DoS风险足以对系统安全和可用性造成实质性威胁，必须修复（比如改用JPA的Criteria API动态构造排序，或者对orderBy参数做严格的白名单校验）。

内容的提问来源于stack exchange，提问作者Macok