What perils are there in allowing user input of parts of an ODBC connect string?

Question

I'm developing an application that allows user to input hostnames, database names, usernames, and passwords for database access. The application will construct a ODBC connect string by filling in the placeholders. In C, that would translate to something like:

snprintf(connStr, sizeof(connStr),
         "DRIVER={%s};SERVER={%s};DATABASE={%s};UID={%s};PWD={%s}",
         myDriver, hostName, dbName, userName, passWord);

First thing I thought -- I need to excise the ";" character from everything. (And instruct users their passwords can't contain semicolons.)

Am I vulnerable to some kind of hostile input in this case? (Before you ask, yes, I will check for excessively large input. You can assume the connStr buffer will be enough. Either that or I'll use a higher level language with managed string types.)

Answer 1

To expand a little on one of @Sigtran's points, filtering on special deliminator characters is of course a key control when protecting against injection attacks, however it is also advisable to protect against the potential for creative encodings by utilising as restrictive as possible a white-list approach rather than simply replacing characters such as ; ' etc. Some regex such as this could perhaps be used (if you don't break legit functionality with only alpha/num/dashes of course):

/[^A-Za-z-_0-9]/g, ""

Answer 2

Well, I don't know whether this code is vulnerable. I don't know much about the format of ODBC connect strings.

But, to be honest, that code gives off bad smells to me. Even though I don't know of a specific attack, it smells like a potential security risk. It smells like it might be an injection vulnerability waiting to happen.

How confident are you that you know the complete list of all metacharacters the database driver might interpret when processing the ODBC string? (Does it treat backslashes as escapes? What if one of the user-defined parameters includes a close curly brace, some stuff, and another open curly brace? What if one parameters includes an open curly brace but no close, and a later parameter includes a close curly brace, what happens?) How confident are you that you know what character encodings the database driver might use when parsing the connect string? How confident are you that this will never change, not for any future version of the database you use, or for any other database you might ever switch to in the future? I know I wouldn't be confident that I know the answers to any of these questions. Maybe you know more than I.

If it were me, I would not expose myself to these risks. I would be wary. It seems unnecessary to take these risks. Instead, I would suggest building a whitelist of characters that seem OK, and restrict all of those strings to use only characters from within the whitelist. Maybe this is unnecessary caution, but it's what I'd do.