posted 17 years ago
I have never been convinced of the ability of an automated tool to definitively find vulnerabilities. The tableName value that is being passed to the PreparedStatement could very well being retrieved from a drop down menu. If that happens to be the case, and the tableName is being pulled from a controlled vocabulary of some sort, then there is no "vulnerability".
In the case that you have a limited amount of possible table names, then one solution would be to kill the query if the tableName is not in the database before the SQL statement is executed. Just from your little snippet, you will know ahead of time whether or not the query is valid because the table name will be in the map. If it isn't, then you would want to display some other message instead.
Another means of preventing SQL injection is to have a custom error page that catches the SQL error message and displays a generic error message. SQL injection works by sending specially crafted queries, and by reading the error messages generated by these sort of queries. The error messages then give them enough information to fully attack the database. This isn't the case in your example though. If the table name is not in the database, the query will fail, so a simple "If the tablename exists in the map, then execute the query" should suffice.
It's also a good idea if you frequently work with SQL databases to maybe read a PDF or two on the subject just to gain some understanding. SQL injection is fundamentally easy to understand, and only marginally harder to implement.
EDIT: Just as a CMA, I am basing my answer only on the small snippet of code you have given and should be taken as an example only. Obviously I have no way of knowing what else you may have going on with your application as far as SQL access.
[ August 20, 2007: Message edited by: Chad Clites ]