db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Why projects fail... wuz... Re: unable to execute procedure
Date Wed, 05 Apr 2006 19:16:25 GMT
Michael Segel wrote:

> On Wednesday 05 April 2006 12:33 pm, Daniel John Debrunner wrote:
> 
>>Michael Segel wrote:
>>
>>>On Tuesday 04 April 2006 6:23 pm, Daniel John Debrunner wrote:
>>>
>>>>Daniel John Debrunner wrote:
>>>>
>>>>>May I suggest that if you are writing samples for others to use that you
>>>>>demonstrate use of parameter markers in PreparedStatements. This will
>>>>>perfom better on Derby and all other relational database engines.
>>>>
>>>>Another reason to use PreparedStatements is to avoid all the security
>>>>concerns that come with SQL injection issues.
>>>
>>>[SNIP]
>>>
>>>Uhm, I'm afraid this has nothing to do with the issue at hand, along with
>>>the fact that its not exactly true....
>>
>>Could you expand on what is "not exactly true"?
>>
> 
> Sure.
> 
> Your said "Another reason to use PreparedStatements is to avoid all the 
> security concerns that come with SQL injection issues." as a benefit of a 
> prepared statement over a regular statement.
> 
> This is not 100% true.  You're implying that using a Statement has some stigma 
> of security concerns. You can effectively use a Statement in a manner that 
> does not create a potential of SQL injection issues. Thus no benefit.

Any time you build the SQL text from user input you run the risk of SQL
injection, your example below even shows that. I was assuming the
typical model with PreparedStatements that the SQL text is fixed by the
application and parameter subsitution is performed using parameter
markers and not modifying the SQL text.

> Again looking at the code :
> 
> String s1 = "SELECT * FROM employee WHERE emp_id = "+empID+";";
> String s2 = "SELECT * FROM employee WHERE emp_id = ?";
> 
> Now in both statements, you are passing in the emp_id, presumably from the end 
> user's input.
> 

> 
> Now... Note that there is no chance of SQL Injection, hence your argument of 
> an advantage of using PreparedStatement is moot.

With the statement case there is every chance of SQL injection. If empID
is a String (or becomes a String later when someone modifies the
application) then SQL injection is possible. With the PreparedStatement
it isn't.

Dan.


Mime
View raw message