4

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.

I have already looked at this question. 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?

Community
  • 1
Shurmajee
  • 7,335
  • 5
  • 28
  • 59

2 Answers2

2

Using an abstraction layer is not meaningful prevention; applications that use such layers are still often vulnerable to SQL injection.

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:

  • Pick a good library, one with a safe API that is easy to use
  • Develop coding standards that mandate the safe API and train developers to use this
  • Perform peer review or static code analysis to enforce use of the safe API
  • Use penetration testing and WAFs as a final layer of defence
paj28
  • 32,906
  • 8
  • 93
  • 130
0

It's great that the abstraction layer prevents direct access to the database, but I would not rely on it as your only safeguard. If you have an abstraction layer in place because the application relies on it for use, and it helps block SQLi, then great. But I would not implement an abstraction layer JUST for security purposes. There are many other documented ways to defeat SQLi that are easier to implement. SQLi is all about user input and passing it through one more layer will not be as effective as stopping it before it has a chance to get close to the database.

Jason Higgins
  • 647
  • 4
  • 8