Problem - Kevin Tafuro

Solution
Perform data validation at all levels whenever possible. At the very least, make sure
data is filtered on input.
Match constructs that are known to be valid and harmless. Reject anything else.
In addition, be sure to be skeptical about any data coming from a potentially insecure
channel. In a client-server architecture, for example, even if you wrote the client,
the server should never assume it is talking to a trusted client.
Discussion
Applications should not trust any external input. We have often seen situations in
which people had a custom client-server application and the application developer
assumed that, because the client was written in house by trusted, strong coders,
there was nothing to worry about in terms of malicious data being injected.
Those kinds of assumptions lead people to do things that turn out badly, such as
embedding in a client SQLqueries or shell commands that get sent to a server and
executed. In such a scenario, an attacker who is good at reverse engineering can
replace the SQLcode in the client-side binary with malicious SQLcode (perhaps
code that reads private records or deletes important data). The attacker could also
replace the actual client with a handcrafted client.
In many situations, an attacker who does not even have control over the client is nevertheless
able to inject malicious data. For example, he might inject bogus data into
the network stream. Cryptography can sometimes help, but even then, we have seen
situations in which the attacker did not need to send data that decrypted properly to
cause a problem—for example, as a buffer overflow in the portion of an application
that does the decryption.
You can regard input validation as a kind of access control mechanism. For example,
you will generally want to validate that the person on the other end of the connection
has the right credentials to perform the operations that she is requesting.
However, when you’re doing data validation, most often you’ll be worried about
input that might do things that no user is supposed to be able to do.
For example, an access control mechanism might determine whether a user has the
right to use your application to send email. If the user has that privilege, and your
software calls out to the shell to send email (which is generally a bad idea), the user
should not be able to manipulate the data in such a way that he can do anything
other than send mail as intended.
Let’s look at basic rules for proper data validation:
Assume all input is guilty until proven otherwise.
As we said earlier, you should never trust external input that comes from outside
the trusted base. In addition, you should be very skeptical about which
72 | Chapter 3: Input Validation
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.