commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: Checking if a String is both HTML and SQL safe
Date Sat, 30 Aug 2003 03:45:47 GMT

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

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

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


View raw message