On Fri, 29 Aug 2003, Marcelo Bello wrote:
> But then a user could input something nasty and execute some arbitrary SQL > statement after the select statement. (Imagine if the user input something > like '; <arbitrary sql statement>;) > > Some of you said that PreparedStatements (I use it) is safe against this > kind of things but are you really sure? The Java API doesn't explicitly > say that. In the end it comes down to the driver implementation. In principle, and I suspect in practice, PreparedStatements are safe against this, but driver bugs could allow someone to get around it. However, it's as good as any escaping solution, as that has the same level of risk of bugs allowing someone to squeeze through. Some drivers go further and refuse to execute multiple statements in an SQL, regardless of type of Statement used. This is definitely driver specific. The biggest problem area is probably the keyword search concept. While updates/inserts are obviously risky, there is little feedback. Search implicitly has feedback. Ensure that you never show an SQLException to the user will help to make it harder for anyone to find cracks. Also ensuring that you statically type the results from SQL searches will make it harder for a user to gauge the success of their SQL injection. A null pointer exception won't tell them much when they try to select the password column. This is all quite a shame as it's nice to have output renderers that take any SQL output and happily show it. As often is the case, extreme security robs code of beauty. You could also setup some unit tests and attempt to break the driver in question. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
