While performing a pentest for a Java based application I came across an SQL (ac

Question

While performing a pentest for a Java based application I came across an SQL (actually HQL) error by simply putting a single quote in one of the request parameters and breaking the syntax of the query. But as the application made use of Hibernate Query Language as an intermediate layer between the application and the database, I was unable to directly access the database.

HQL does not support Union or time delay based controls which we generally exploit as pentesters. I was only able to extract all the entries from the table in question. Note that as the injection was found in a simple search functionality there was no confidential data in the table. I was unable to extract any database or system related information.

My question here is, can using an abstraction layer like this be suggested as a preventive measure during the development phase of an application? Because in my understanding it can really minimize the damage potential of an SQLi vulnerability (At least in my given case where there is no real critical data in the database)

Am I missing out on something important here?

Explanation / Answer

Sticking with your example of Hibernate, some ways to query are safe; some ways are unsafe. I've not actually come across an example like you describe that is partially safe, but it makes sense. I've come across several that are effectively direct SQL injection.

So, with an abstraction layer in place, you are still relying on developers to use the safe query API. This is not all that different to standard SQL interfaces (like JDBC) where there is a safe API (parameterised queries) and an unsafe API (dynamically building SQL). Either way, you are relying on developers to use the right one.

You might wonder, has someone invented an abstraction library that only has a safe API? If there's no unsafe API then there's nothing for developers to abuse. As far as I know, no such library exists, and this is because there are odd occasions that the unsafe API is needed. Remember that using the unsafe API is not necessarily a security vulnerability - the code may only be using data from trusted sources, or it may do its own sanitisation.

So the defences are:

Related Questions

Navigate

• Browse (All)
• Browse W
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.