Subject | Re: [Firebird-Java] Re: JayBird: Problems with Prepared Statements |
---|---|
Author | David Jencks |
Post date | 2005-09-06T19:36:31Z |
On Sep 6, 2005, at 12:15 PM, pifproject wrote:
from user input, a malicious user will be able to supply input that
will result in an sql string that will at best crash your database
server and at worst give them root access on your database server.
Intermediate attacks will let them delete tables, run arbitrary stored
procedures, etc etc. This is easier on products such as mssql, but I'm
sure a determined adversary could come up with something to break
firebird.
The solution is easy and obvious: never, ever, execute sql that
includes a string computed from user input. Always use prepared
statements and put the user input into the parameters. You may think
you have written a foolproof input validation scheme, but you are
almost certainly wrong.
david jencks
> - Roman Rokytskyy writes:No, I mean that if you construct an sql string using input computed
> > It is conceptually wrong to use prepared statement only to
> > convert question marks into string representation of the parameters
>
> Thanks for responding! It's not only for that, I have to manipulate
> the String, as mentioned.
>
> - David Jencks writes:
> > I recommend you use only prepared statements, even for static sql.
>
> Thank you for the recommendation! If I got you right (?), you mean
> that a prepared statement provides the advantage of precompiling the
> SQL code to see if it is executable, according to the security
> requirements of the particular database system.
>
>
from user input, a malicious user will be able to supply input that
will result in an sql string that will at best crash your database
server and at worst give them root access on your database server.
Intermediate attacks will let them delete tables, run arbitrary stored
procedures, etc etc. This is easier on products such as mssql, but I'm
sure a determined adversary could come up with something to break
firebird.
The solution is easy and obvious: never, ever, execute sql that
includes a string computed from user input. Always use prepared
statements and put the user input into the parameters. You may think
you have written a foolproof input validation scheme, but you are
almost certainly wrong.
david jencks