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),
         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.)

  • You are on the right track - using 'n' functions is helping a lot, you also might consider filtering characters out (using reg expressions, using white listing e.g. allow only a-zA-Z0-9 and do the same when creating passwords/ usernames for databases). Else you might be vulnerable to sql injections /etc
    – Sigtran
    Mar 30, 2011 at 11:08

2 Answers 2


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, ""

  • While I'm not arguing your point, because it's definitely valid, I'm curious what could be injected? I don't think ODBC strings are executable, in the sense of SQL or shell?
    – Steve
    Mar 30, 2011 at 18:32
  • Pretend myDriver contains a full connection string as its variable. What happens to the values in the remaining variables? Are they ignored? Does the application fail? Does it somehow segfault? Does overloading the password value the same way allow you to overwrite the earlier values?
    – Jeff Ferland
    Mar 30, 2011 at 19:47
  • @SteveS It probably shouldnt read as an "SQL injection", but as an "injection" on its own :) google "Connection String Parameter Pollution Attack" to get more info on it - there is a nice paper written as well.
    – Sigtran
    Mar 30, 2011 at 20:30
  • 1
    @Sigtran, @Jeff, I read the paper, but it didn't describe any specific attacks that seem applicable in this setting, as long as semicolons are filtered. All of the attacks in that paper require a semicolon to appear somewhere in an user-defined input. I still think a whitelist is a good idea, on general principles, but @SteveS was asking if there is any attack if we filter semicolon. I don't know of any such attack.
    – D.W.
    Mar 31, 2011 at 7:28
  • @D.W. one example would be \x3B (in C/C++) will give you a semicolon. Im sure a dedicated enough person could find more things wrong. There just too many language specifics that have to be taken into account when designing any kind of login systems & white listing is therefore the most preferable way (and possibly is the only right way).
    – Sigtran
    Mar 31, 2011 at 14:44

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.

  • Definately agree that something triggers my spidey sense about this, can't find much in the way of objectiev reasons why though! Could it be that if users have remote access to trigger this functionality, could it be used as proxy for attacking arbitrary DBs? The 'ODBC Connection String Structure Specification' defines these: SC, LCB, RCB, EQ, ESCAPEDRCB, SpaceStr -> %x3B, %x7B, %x7D, %x3D, 2RCB, *(SP) as the control characters involved in these strings. I can't see any way around the semicolon.
    – TobyS
    Mar 31, 2011 at 10:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .