A Strategy for Defending Against Input Attacks

The simplest and by far the most effective way to defend your application from input attacks is to validate the data before performing any further processing. To achieve these goals, you should adhere to the following strategies:

Define a trust boundary around the application.
Create an input chokepoint.

First, all applications have a point in the design where the data is believed to be well-formed and safe because it has been checked. Once the data is inside that trusted boundary, there should be no reason to check it again for validity that is, assuming the code did a good job! That said, the principle of defense in depth dictates that you should employ multiple layers of defense in case a layer is compromised, and that is quite true. But I'll leave it to you to find that balance between security and performance for your application. The balance will depend on the sensitivity of the data and the environment in which the application operates.

Next, you should perform the check at the boundary of the trusted code base. You must define that point in the design; it must be in one place, and no input should be allowed into the trusted code base without going through that chokepoint. Note that you can have multiple chokepoints, one for each data source (Web, registry, file system, configuration files, and so on), but data from one source should not enter the trusted code base through any other chokepoint but the one designated for that source.

CAUTION
Reusable components, such as DLLs, ActiveX controls, and reusable class libraries, should be designed and written carefully. These components should not trust the caller because the caller could be any code. Any externally reachable function, variable, method, or property should validate all data.

As you can see, the concept of the trusted boundary and chokepoint are tightly related. Figure 10-2 graphically shows the concepts of a trust boundary and chokepoints.

figure 10-2 the concept of a trust boundary and chokepoints.

Figure 10-2. The concept of a trust boundary and chokepoints.

Note that the service and the service's data store have no chokepoint between them. That's because they're both inside the trust boundary and data never enters the boundary from any data source without being validated first at a chokepoint. Therefore, only valid data can flow from the service to the data store and vice versa.

A common vulnerability on the Web today is cross-site scripting errors. These errors involve malicious input that is echoed in the unsuspecting user's browser from an insecure Web site. The malicious input comprises HTML and script. I'm not going to give the game away; it's all explained in detail in Chapter 13. Many Web sites have them, and the sites' administrators don't know it. I spent time in early 2001 providing security training for some developers of a very large Web site that has never had such an issue. They have never had these issues because the Web application has two chokepoints, one for data coming from the user (or attacker) and another for data flowing back to the user. All input and output goes through these two chokepoints. Any developer that violates this policy by reading or writing Web-based traffic by using alternate means is spoken to! The chokepoints enforce very strict validity checking. Now that I've brought up the subject, let's discuss validity checking.