Input Validation

Whenever software processes input, it should make sure that this input is in the expected form. From a functional point of view, this will ensure a high data quality level. From a security point of view, this will prevent unexpected data from altering the intended execution of the program.

Software processes input from various sources:

• User input from a GUI
• Parameters from a configuration file
• Data from a database
• Data from remote function calls
• Etc.
  Caution

  Risk:

  If input is not sufficiently validated, the application processing the data might crash or could be tricked into performing unwanted tasks.

Web Dynpro (ABAP and Java) performs type validation. Therefore applications do not have to check for the correct data type.

Basically, you should validate your input. To achieve that goal, you have to provide a validation function for each input variable. You might group the variables (for example, all input strings) and write one validation function for each group (for example, string validator), which increases your efficiency. The task of writing validation code is a step-wise procedure. In the case of Web Dynpro, the framework automatically performs the type validation before you can even access a variable. So the first three steps of the following list have been already performed. Consequently, in Web Dynpro you only need to start your additional input validation at the fouth step of the following input validation 'to do' list:

1. Existence and length check
2. Canonicalization
3. Type check
4. Range check
5. White list filter
6. Black list filter

These steps are explained in more detail below:

Step 1: Existence and length check

It must not be possible to attack the application simply by omitting a necessary variable or feeding in data packets that are either too long or too short. So, first of all, your validation function needs to check if the relevant variable exists and has the correct length.

Step 2: Canonicalization

Canonicalization means that the input variable's content is transformed into its simplest and shortest representation. Many attack methods depend on the usage of 'polymorph representation', that is, an unusual or overly complicated form that is designed to evade filter mechanisms. So the transformation into its simplest form is fundamental for successful filter mechanisms.

Step 3: Type check

Since attackers should not be able to harm the application by feeding input data of the wrong type to it (such as strings instead of dates), the validation function has to check that the variable is of the correct type.

Step 4: Range check

You should then check if the variable's values are in the correct range. Clearly, this is only possible for variables with a definable range of values (like numbers). It is imperative that you define the limits precisely here. You should consider where the boundaries lie for all input.

Step 5: 'White list' filter

If a variable simply has no clear range of values (for example, strings), a range check would be pointless. In this case, your validation function should contain a list of allowed values and check the input against this instance. Such an instance is called a 'white list' filter.

Step 6: 'Black list' filter

There may be cases where you cannot even implement a white list filter. In this situation, you should at least write a black list filter function:  this is better than doing no filtering at all. Doing nothing here regularly has detrimental effects for the security of your application.

Input is often not validated for any one of the following reasons:

• Input is not recognized as such
• The source of input is trusted
• The implicit assumption that someone else has already performed the validation
• Performance is more important than security
• Insufficient time in the project

Not validating input is a high security risk. Ensure that you consider the advantages and disadvantages in detail whenever you have priorities other than security.