Problem - Kevin Tafuro

components of the system are trusted, even after you have authenticated the user
on the other end!
Prefer rejecting data to filtering data.
If you determine that a piece of data might possibly be malicious, your best bet
from a security perspective is to assume that using the data will screw you up
royally no matter what you do, and act accordingly. In some environments, you
might need to be able to handle arbitrary data, in which case you will need to
treat all input in a way that ensures everything is benign. Avoid the latter situation
if possible, because it is a lot harder to get right.
Perform data validation both at input points and at the component level.
One of the most important principles in computer security, defense in depth,
states that you should provide multiple defenses against a problem if a single
defense may fail. This is important in input validation. You can check the validity
of data as it comes in from the network, and you can check it right before you
use the data in a manner that might possibly have security implications. However,
each one of these techniques alone is somewhat error-prone.
When you’re checking input at the points where data arrives, be aware that components
might get ripped out and matched with code that does not do the
proper checking, making the components less robust than they should be. More
importantly, it is often very difficult to understand enough about the context of
the data well enough to make validation easy when data is fresh from the network.
That is, routines that read from a socket usually do not understand anything
about the state the application is in. Without such knowledge, input
routines can do only rudimentary filtering.
On the other hand, when you’re checking input at the point before you use it,
it’s often easy to forget to perform the check. Most of the time, you will want to
make life easier by producing your own wrapper API to do the filtering, but
sometimes you might forget to call it or end up calling it improperly. For example,
many people try to use strncpy( ) to help prevent buffer overflows, but it is
easy to use this function in the wrong way, as we discuss in Recipe 3.3.
Do not accept commands from the user unless you parse them yourself.
Many data input problems involve the program’s passing off data that came
from an untrusted source to some other entity that actually parses and acts on
the data. If the component doing the parsing has to trust its caller, bad things
can happen if your software does not do the proper checking. The best known
example of this is the Unix command shell. Sometimes, programs will accomplish
tasks by using functions such as system( ) or popen( ) that invoke a shell
(which is often a bad idea by itself; see Recipe 1.7). (We’ll look at the shell input
problem later in this chapter.) Another popular example is the database query
using the SQLlanguage. (We’ll discuss input validation problems with SQLin
Recipe 3.11.)
Understanding Basic Data Validation Techniques | 73
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.