Deep application boundary validation

When developing an application security is (should) always be a point of attention. Unfortunately security is commonly a point of attention that is addressed when architects discuss the implementation of the application. At that stage security comes into play when people are looking at how to put in firewalls, host hardening, database security and communication with other servers and services. These are all valid points of attention and do need the appropriate attention however security should be a point of consideration in a much earlier stage of the process. 

Boundary validation is a method used to validate input coming in from an untreated source into a trusted source. A simple example of boundary validation (and one that is commonly done) is the validation of input given by a user into an application. If we take for example a web based application the input from the user coming from the Internet or intranet is considered untrusted and is validated when crossing the boundary from the untrusted user space into the trusted server side scripting.

This form of boundary validation is commonly done and implemented in a lot of (web based-) applications. Even though this is a good approach this is in many cases not enough. Even for the most simple application this can possibly not be enough. As we are using object orientated programming in most cases one function calls another function to perform some actions, by having functions calling functions (calling functions) it is very likely that if you implement only a boundary validation when receiving the data from the user that is can potentially cause a security risk in one of the other functions.

As an example, during boundary validation of a login function it is checked if the input on a order entry screen against the rules for the order entry screen it can be very well that you have secured against the input of malicious data for this specific function however as the user input is commonly used as input for all other kind of functions it might be that some input that is considerd not malicious for the order entry screen can be triggering a vulnerability in a total different function somewhere down the line. This might result in an attacker gaining acces to data or functionality somewhere else in your application which was not the intention of the developer.

To prevent such an attack it is advisable to not only consider data coming into the application as a whole to consider unsafe however considering all data passed between functions to consider as unsafe. This holds that you will have to do boundary checking at every function and not only the functions exposed to the user. This also holds that you cannot do boundary checking only at the application server, you will also have to make sure boundary checking is done in for, for example, all your database procedures and functions. 

By implementing such a model you will harden your application even more against attacks. Implementing such a strategy is causing more work to be done during coding however this form of attack, even though it less commonly know, is quite regularly used by attackers to gain access to systems and data.