I haven't seen the code... but, I I understand correctly what you are
describing, "does the regular escaping like setString(), but doesn't
include th einput in quotes), I don't understand how it helps to fix
that "security problem" that started all this...
Won't something like "select * from users where id in ?" get
translated into 'select * from users where id in (1);drop table users'
just like before after a
setObject (1, "(1);drop table users", Typed.NUMERIC)?
As far as I remember, setString () does not escape semicolons, right?
Dima
Barry Lind wrote:
>
>
> 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
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly