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 3F1D5E00.3090807@xythos.com
Whole thread Raw
In response to Re: Patch applied for SQL Injection vulnerability for setObject(int,Object,int)  (Oliver Jowett <oliver@opencloud.com>)
Responses Re: Patch applied for SQL Injection vulnerability for setObject(int,Object,int)  (Oliver Jowett <oliver@opencloud.com>)
List 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
>




pgsql-jdbc by date:

Previous
From: Fernando Nasser
Date:
Subject: Re: IN clauses via setObject(Collection) [Was: Re: Prepared
Next
From: Barry Lind
Date:
Subject: Re: patch: tiny patch to correct stringbuffer size estimate