Does Hibernate's createCriteria() sanitize input?

Question

Came across some code today that uses Hibernate to perform a query. The query uses a value submitted from a form. It made me curious as to whether or not this sort of code "sanitizes" its input.

public List<School> search(String query) {
    Session session = this.getCurrentSession();
    query = "%" + query + "%";
    Criteria criteria = session.createCriteria(getPersistentClass());
    criteria.createAlias("country", "a");
    Criterion nameCriterion = Restrictions.ilike("name", query);
    Criterion cityCriterion = Restrictions.ilike("city", query);
    Criterion countryCriterion = Restrictions.ilike("a.name", query);
    Criterion criterion = Restrictions.or(Restrictions.or(nameCriterion, cityCriterion), countryCriterion);
    criteria.add(criterion);
    return criteria.list();
}

Is this safe?

Answer 1

Hibernate Criteria Queries are quiet safe in terms of Sql Injection since they pass strings as parameter while performing any fetch. Even, Hql is quiet safe unless you build the query via string literal.

For more details, you should take a look at queries getting fired at the database level by switching on hibernate sql logging.

Answer 2

If you think to SQL injection attacks, then yes, Hibernate Criteria API is safe.

It will generate the underlying query by first compiling it from the specified query fields and only after apply the query parameters (It should use a classical PreparedStatement). This way the JDBC driver will know which part of the query are fields and which part are parameters. Then the driver will take care to sanitize the parameters.

Tough you should take care with the SQL restrictions applied on the Criteria, if you need to place parameters there. For example

String vulnerable = //parameter from user interface 

criteria.add(
    Restrictions.sqlRestriction("some sql like + vulnerable") //vulnerable

criteria.add(
    Restrictions.sqlRestriction("some sql like ?", 
              vulnerable, Hibernate.STRING)) //safe

In this case the vulnerable parameter could "leak" in to the query fields part and be bypassed by JDBC driver checking as in a normal vulnerable SQL query.