sql injection < resolved by user context execution

Aug 23, 2011 at 8:58 PM

this set of procedures looks like it would be prone to sql injection.  what do you do to protect against this?

Aug 23, 2011 at 9:24 PM
Edited Aug 24, 2011 at 12:15 AM

The versatility of the solution is based on creating/executing SQL statements on the fly. This dynamic behavior is theoretically a potential target for SQL injections.

Therefore it's crucial, that the statements executed in parallel by the privileged agent proxies are running in the context of the initiating user, who has passed-in the genuine statement thru the stored procedure PROC_BOOST_Job_ADD_Entry. This logic prevents injections, which exceed the permissions of the calling user, but does not protect the calling host application to send 'bad' statement code. The calling application with in its database user context must ensure itself to provide a 'safe' environment. Like in any regular environment without using modules like SQL Parallel Boost, this may be achieved thru appropriate user context execution and safe application coding with optional preliminary parsing and/or execution testing, which prevents the injection of unwanted injecting 'parameter values'.

The execution in the calling user context is a standard feature of the Enterprise Edition an may be added in the Community Edition on your own.