Question

So we have a custom logger (really wanted to use Log4Net, just wouldn’t work for this case). From a config file, you can configure the name of the table that will be inserted into.

I am parameterizing the insert statement, but the configurable table name will be used in an insert statement, and it’s a potential vector for attack. Here’s an example of the statement that will be built:

"insert into " + theTableName + " (static column list) values(parameterized list of values)"

So my inserted values are parameterized, and pretty safe, it’s theTableName that could contain nasties.

My question is, what can I do to sanitize the table name? I think the nature of the code an attacker would inject would have to be a little different from the garden-variety. — instead of a tick, you would potentially close off the statment with “table name() values(); do something bad —

(or something like that, I suppose). To that end, I was thinking about checking for the “;”, and the “–“.

Can anyone suggest a better way to sanitize this? (this will be used with Oracle and SQL server)

Answer 1

I think you have a potentially bigger problem, which is that the user could specify a syntactically safe and valid table name that simply doesn’t exist in the database.

Therefore, I’d do this:

1. Build the INSERT string (including the table name) only once, when you load the config file.

2. Verify the table name at that time by checking the system metadata to ensure that it’s a real, valid table.

At that time you can warn the user that logging is off because the table “theTableName” does not exist in the database.