Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers, this is the security community's go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

HQL Injection Exploitation in MySQL

Are you familiar with an HQL injection exploitation? Chances are you’re not. While you may assume it’s intuitive since it’s related to SQL injection, you’re right, but it’s a little bit more complex.

HQL stands for Hibernate Query Language. Hibernate is an Object-Relational Mapping (ORM) that maps class definition (within a source code) with associated SQL tables. The HQL is a language similar to SQL but operating on persistent objects instead of directly operating with tables and columns. The HQL query is translated to SQL by the Hibernate framework, then the SQL query is passed into the database.

If we have an injection in HQL syntax, we cannot exploit it as a normal SQL injection as HQL language has its own syntax and it's more restricted (for example, there is no way to query unmapped tables). But a couple of years ago Russian security folks found a way to escape from the HQL context into the SQL context and communicate directly to the database. To be honest, I couldn’t find any English articles about how to exploit it, but there is some good Russian research. I’ll show how to exploit it using an example I recently found during a customer project. The escaping methods are different across databases and in my case, it was a MySQL database.

The initial request/response and parameter I paid attention for were (the POST body is in GWT format):

When I put the quote in the parameter, the server throws the error in the response:

Such special characters like vertical bar (‘|’) or backslash (‘\’) will break the GWT syntax, so I need to encode them properly. The additional encoding for the GWT format is:

  • | => \!
  • \ => \\

Before escape from the HQL context, I had to understand what database I have a deal with. So, I ran a couple of tests:

Payload Result
orderInGroup' error (EX)
'orderInGroup' ok (OK)
'orderInGroup'\!\!'x error (EX)
'orderInGroup'\!\!'x' ok (OK)
'orderInGroup'\!\!'x'\!\!'' ok (OK)
'orderInGroup'\!\!str(46)\!\!'' ok (OK)
'orderInGroup'\!\!substr('x',1,1)\!\!'' ok (OK)

After a little research by playing with the most well-known databases, such as MySQL, MSSQL, Oracle, the last payload could work only for MySQL. So, only now I could try to escape from the HQL context.

The set of characters \'' (backslash, single quote, single quote) escapes from the HQL context into the MySQL context. The single quote escapes the other single quote in the HQL query context, but the backslash is the normal symbol. It is opposite for MySQL, the backslash escapes the single quote, but not another single quote. Hence, when the Hibernate Framework parses the query it sees the one query, when it comes to the MySQL database, MySQL sees another query.

Hibernate sees:

'orderInGroup'||'\''|| (select 1)) -- ' // as a string

The payload goes to MySQL and MySQL sees:

'orderInGroup'||'\''|| (select 1)) -- ' // string '\'', logical 'or', select query

The screenshot below shows the positive result from using the payload (the response is “OK”):

After I got escaped, I wanted to retrieve some information from the database. The injection appears in the 'order by' query part. As the application does not reveal the queried data, I used 'boolean-based blind' exploitation technique. The updatexml MySQL function is the most suitable for this purpose because it has a specific behaviour: it throws an error if the second parameter is not a valid XPath query string or returns no value if the XPath query is correct.


The important part is that the error is being thrown only after the second parameter is evaluated (which contain the 'if' clause). So, depending on whether the ‘if’ clause is successful the application returns or does not return the error. This type of injection is called 'boolean-based blind' HQL injection. It allows an attacker to extract data character-by-character.

The screenshot shows the process of revealing characters one by one by using Burp Suite Intruder:

The whole obtained value will be:

And, finally, the decoded 'user()' value is '[...]PROD_SELF[...]'.

More examples for other databases such as Oracle, Postgresql, and MSSQL can be found here.