Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question
    
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 '11 at 11:08
add comment

2 Answers

up vote 3 down vote accepted

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

share|improve this answer
    
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? –  SteveS Mar 30 '11 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 '11 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 '11 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 '11 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 '11 at 14:44
show 5 more comments

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.

share|improve this answer
    
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 '11 at 10:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.