views:

481

answers:

2

I've done some searching around but I have a specific question on SQL Injection and hope I can get some input as I believe I may be getting the wrong end of the stick to do with field data sanitising etc :-

I have a java program calling a stored procedure on an iSeries. The stored procedure has CL / RPG code behind the scenes. The stored procedure is called by way of parameters with the data coming from a web page. For example the call would look like the following:-

call library.prog('field1Value', 'field2Value')

Do I need to worry about any characters entered via the website into 'field1Value' etc or, because it is a stored procedure call, does the danger of sql injection not exist? Does it depend on whether the RPG program behind the scenes uses 'field1Value' in its own SQL statement as part of that processing?

The field lengths passed into the proecdure are fixed length so we cannot, for example, convert 'dodgy' characters into their html equivalent.

Appreciate any (I'm anticipating this might be a stupid question!) feedback (not necessarily iSeries specific) on this.

A: 

If you're using the JDBC CallableStatement, then you're safe. CallableStatement is just a subtype of PreparedStatement, and SQL injection attacks should not be possible. The only way I can think of for this not to be true would be if your stored procedure was executing dynamic SQL.

skaffman
We are using CallableStatement...
oidsman
A: 

unless you are using those parameters to construct dynamic sql in the proc itself you should be fine

also you cannot clean it by checking the parameters

see here: SQL teaser..try protecting this

below is sql server syntax

I can call a proc like this

prDropDeadFred ' declare @d varchar(100) select @d = reverse(''elbaTdaB,elbatecin elbat pord'') exec (@d)'

or like this

prDropDeadFred ' declare @d varchar(100) select @d = convert(varchar(100),0x64726F70207461626C65204E6963655461626C652C4261645461626C65) exec (@d)'

or 5000 other ways that you won't know about

SQLMenace
If I find that the proc is constructing some dynamic SQL using one or more field values, I assume that the proc should take care of 'cleaning' the data to ensure no SQL injection is possible? Is there any guidance on how this should work?
oidsman
you can't clean that, see link in answer
SQLMenace