Re: Patch applied for SQL Injection vulnerability for setObject(int,Object,int) - Mailing list pgsql-jdbc

From Barry Lind
Subject Re: Patch applied for SQL Injection vulnerability for setObject(int,Object,int)
Date
Msg-id 3F1EC024.8000006@xythos.com
Whole thread Raw
In response to Re: Patch applied for SQL Injection vulnerability for setObject(int,Object,int)  (Fernando Nasser <fnasser@redhat.com>)
Responses Re: Patch applied for SQL Injection vulnerability for setObject(int,Object,int)  (Dmitry Tkach <dmitry@openratings.com>)
List pgsql-jdbc

Fernando Nasser wrote:
> Barry Lind wrote:
>
>> Oliver,
>>
>> Yes that will no longer work.  But syntactically it shouldn't anyway.
>> You are passing a set of strings and saying the type is NUMERIC.  What
>> will still work is passing a set of numeric values:
>>
>>    stmt.setObject(1, "(1, 2, 3)", Types.NUMERIC);
>>
>
> Can we pass a set of strings?  Otherwise it is a half-way solution.
>
> stmt.setObject(1, "('a1', 'b2', 'c3')", Types.VARCHAR);

I am not sure what you are asking, but if you make the above call you
will send the following to the server:

where ... in (\'a1\', \'b2\', \'c3\') ...

Which is as it has always been since Types.VARCHAR caused proper
escaping.  The commited change causes the above to happen even when you
say the type is Types.NUMERIC.

I don't know what you mean by a half-way solution, the fix closes the
security vulnerability and makes the behavior for Types.NUMERIC
consistent with the behavior of Types.VARCHAR.

thanks,
--Barry



pgsql-jdbc by date:

Previous
From: Erik Price
Date:
Subject: Re: RFC: Removal of support for JDBC1 drivers.
Next
From: Barry Lind
Date:
Subject: Re: RFC: Removal of support for JDBC1 drivers.