¿Es posible SQLi a través de una variable "Larga" en Java / Hibernate?

En tu ejemplo de Java:

Query query = entityManager.createQuery(
        "SELECT UPPER(request.attributeValue) FROM PreOrderedRequests request 
         WHERE request.status = :status AND request.report.id = " + var1);

Si var1 es un byte , short , int , long , entonces no hay ninguna vulnerabilidad de seguridad. Estos serán interpretados por el servidor SQL como el desarrollador pretende.

Si las 'declaraciones preparadas en caché' están habilitadas, dicho código degradaría la efectividad de la caché, pero eso no calificaría como un problema de seguridad.

Si var1 fuera double , float o char , entonces un atacante podría causar un error de sintaxis SQL (con Infinity , -Infinity o algún actor inesperado de char ), pero Sería raro que ese error se convierta en un ataque SQLi utilizable. Esto sería principalmente un medio de recopilar información. (es decir, las páginas de error podrían revelar una vulnerabilidad en algunos casos de borde)

Si var1 fuera String , obviamente es un problema grave.

Si var1 fuera algún otro Object , entonces el riesgo dependería del método Object 's toString . (es decir, Integer es seguro, pero CharSequence no es seguro, y Collection probablemente no es seguro)

Java es un lenguaje de tipo estático, lo que significa que los tipos se definen en tiempo de compilación.

Entonces, si hay un tipo Long en Java, no hay manera de cambiarlo a String de ninguna manera y hacer una inyección. Si ese es un lenguaje dinámico diferente, entonces es teóricamente posible, sin embargo, algunos marcos web como Play y Grails requieren o recomiendan una definición estática de cada argumento pasado a través de GET y POST.

Por lo tanto, como los parámetros GET y POST se definen de forma estática, durante el análisis de los argumentos, el marco web de Java comprobará si el argumento pasado es realmente algo que se pueda convertir a Long. Si no puede ser así, se lanzará la excepción y se producirá un error en toda la solicitud sin iniciar ninguna consulta SQL.

Incluso si el argumento GET / POST se define como String, ya que var1 se escribe como Long, siempre se convertirá a Long y nunca se reemplazará con String.

Así que no hay forma de explotar esta concatenación.