Re: Patch applied for SQL Injection vulnerability for setObject(int, Object, int)

From: Barry Lind <blind(at)xythos(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-jdbc-list <pgsql-jdbc(at)postgresql(dot)org>, Kim Ho <kho(at)redhat(dot)com>, Fernando Nasser <fnasser(at)redhat(dot)com>
Subject: Re: Patch applied for SQL Injection vulnerability for setObject(int, Object, int)
Date: 2003-07-22 15:53:36
Message-ID: 3F1D5E00.3090807@xythos.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

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);

thanks,
--Barry

Oliver Jowett wrote:
> On Mon, Jul 21, 2003 at 10:49:14PM -0700, Barry Lind wrote:
>
>
>>Given the ongoing discussion that this SQL injection vulnerability has
>>caused, I decided not to apply the below patch from Kim and instead
>>fixed the problem in a different way. The fix essentially applies the
>>regular escaping done for setString to appropriate values passed to
>>setObject. It does not however add quotes to the value. Thus existing
>>uses of setObject for in clause and array type values will still
>>continue to work.
>
>
> I haven't looked at the updated tree yet, but from your description won't
> this break code that does something like this? :
>
> stmt = conn.prepareStatement("SELECT * FROM table WHERE string_key IN ?");
> stmt.setObject(1, "('a', 'b', 'c')", Types.NUMERIC);
>
> -O
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message pginfo 2003-07-22 15:59:45 Re: jdbc batch performance problem
Previous Message Fernando Nasser 2003-07-22 15:16:06 Re: the IN clause saga