HQL and LINQ query by the type on <any/> with meta-type "string" fails

[druidroad]

HQL and LINQ query by the type on <any/> with meta-type="string" fails with System.Data.SqlClient.SqlException : Invalid column name. Looks like the type makes into SQL query text without single quotes.

To replicate the issue, follow the steps:

1. Map using <any/> with meta-type="string":

<id name="Id">
  <generator class="native"/>
</id>
<property name="Name" />
<any name="Shape" id-type="int" meta-type="string">
  <meta-value value="CircleType" class="Circle"/>
  <meta-value value="SquareType" class="Square"/>
  <column name="ShapeType" />
  <column name="ShapeId" />
</any>

2. Try to query by type using HQL:

var boxes = s.CreateQuery("from ToyBox t where t.Shape.class = Square").List<ToyBox>();

or LINQ:

var boxes =
	(from t in s.Query<ToyBox>()
		where t.Shape is Square
		select t).ToList();

3. The Query will fail witch exception:

NHibernate.Exceptions.GenericADOException : could not execute query
[ select toybox0_.Id as id1_0_, toybox0_.Name as name2_0_, toybox0_.ShapeType as shapetype3_0_, toybox0_.ShapeId as shapeid4_0_ from ToyBox toybox0_ where toybox0_.ShapeType=SquareType ]
[SQL: select toybox0_.Id as id1_0_, toybox0_.Name as name2_0_, toybox0_.ShapeType as shapetype3_0_, toybox0_.ShapeId as shapeid4_0_ from ToyBox toybox0_ where toybox0_.ShapeType=SquareType]
----> System.Data.SqlClient.SqlException : Invalid column name 'SquareType'.
at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters, IResultTransformer forcedResultTransformer)
at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters)
at NHibernate.Loader.Loader.ListIgnoreQueryCache(ISessionImplementor session, QueryParameters queryParameters)
at NHibernate.Loader.Loader.List(ISessionImplementor session, QueryParameters queryParameters, ISet`1 querySpaces)
at NHibernate.Loader.Hql.QueryLoader.List(ISessionImplementor session, QueryParameters queryParameters)
at NHibernate.Hql.Ast.ANTLR.QueryTranslatorImpl.List(ISessionImplementor session, QueryParameters queryParameters)
at NHibernate.Engine.Query.HQLQueryPlan.PerformList(QueryParameters queryParameters, ISessionImplementor session, IList results)
at NHibernate.Impl.SessionImpl.List(IQueryExpression queryExpression, QueryParameters queryParameters, IList results, Object filterConnection)
at NHibernate.Impl.SessionImpl.List(IQueryExpression queryExpression, QueryParameters queryParameters, IList results)
at NHibernate.Impl.AbstractSessionImpl.List[T](IQueryExpression query, QueryParameters parameters)
at NHibernate.Impl.AbstractQueryImpl2.ListT
at NHibernate.Test.NHSpecificTest.GHHQL.Fixture.AnyIs_HqlWithClassNameInTheRight()

There are related issues fixed in a past: NH-2741, NH-2328, NH-3251. The issue NH-2328 has an unit test (NHibernate.Test.NHSpecificTest.NH2328) that demonstrates query by the type on <any/> with meta-type "int". The unit test successfully passes. However if we change mapping from meta-type "int" to meta-type "string", the test will fail.

[hazzik]

The fix for MetaType is easy:

internal string GetMetaValue(string className, Dialect.Dialect dialect)
{
	var raw = keys[className];
	if (baseType is ILiteralType literalType)
	{
		return literalType.ObjectToSQLString(raw, dialect);
	}

	return raw?.ToString();
}

Plus code adjustment to supply dialect into GetMetaValue method.

[druidroad]

Thank you, Alexander. I will make all necessary changes, test and commit the proposed fix.

[fredericDelaporte]

Ideally a way to provide the value as a SQL command parameter would be better.

The ObjectToSQLString current implementations appear to do no escaping, and so they are opened doors for SQL injection. Providing them the dialect was likely done for allowing handling dialect specific escaping, but that is not used currently. Fortunately ObjectToSQLString is currently used in very few cases, like for discriminators and literals in HQL strings. But the more usages we add for it, the more a security issue it will become.
Implementing (in a dedicated PR of course) proper escaping for each dialect would be quite challenging, since it is not just a matter of escaping quotes and backslashes, but also Unicode tricks, all that specifically for each database.

[hazzik]

The ObjectToSQLString current implementations appear to do no escaping, and so they are opened doors for SQL injection.

Not in this case. The value is the value from a mapping file.

Fortunately ObjectToSQLString is currently used in very few cases, like for discriminators and literals in HQL strings.

This case IS discriminator value.

[fredericDelaporte]

Yes, but that still opens some bug possibilities, like someone using a quote in a discriminator value. Of course the bug will very likely be caught at development stage, but that will still be a NHibernate bug.

[hazzik]

In this case it will fail earlier, but I don't think this needs to be addressed in this PR.

[fredericDelaporte]

I will not oppose to using ObjectToSQLString for the case here. I am just writing that if possible, try parameterizing instead.