Best practice to handle Airlock WAF Parameter Exceptions

Applications can easily help Airlock WAF to select appropriate rules and parameter white lists to reduce false positives. This article gives some hints and tipps to integrate application developers in the process of providing information about the format and types of input fields and to ease the use of parameter exception patterns.

It also describes methods to check, if it is safe to add a parameter exception to prevent false positives from the filter engine of Airlock WAF.

Background

Many applications need parameters to control application flow, navigation etc. These parameters are usually not entered by the user but generated by the application, using hidden values. This means that the application programmer “knows” what values to expect and during testing probably never tries to inject malicious code like SQL injections or XSS patterns. This is the reason why Airlock has to check every parameter for attacks: To protect such hidden, insufficiently tested fields as well.

Unfortunately some rules may sometimes generate false positives. These are blocked requests which should not be blocked, because the values should be allowed to pass and reach the application. Almost all false positives are generated by deny rules named "...in Parameter Value". If you would disable these rules, almost every request would go through Airlock WAF without any problem. Obviously this is not the way Airlock WAF should be used.

Parameter Naming Convention

The application developer can help Airlock with some very simple conventions, by marking parameters and therefore communicating to Airlock that, for example, “this is a plain-text multiline input field which I know is correctly written to the database, encoded and correctly escaped, because we tested several use cases with all sorts of special characters”. In the traditional use of filter engines, the application developer would have to communicate the parameter names to the Airlock configuration team, for them to create an exception for each of those parameters. This results in dozens of parameter exceptions, which become increasingly hard to maintain, leading to insecure operation of the filter engine.

There is an easy way for the application developer to mark parameters not to be checked by certain patterns and rules. The concept is that the application developer uses a simple naming convention for input fields, a prefix or postfix such as:

The Airlock configuration for the appropriate mapping has following parameter exceptions:

With this very small and simple convention, the application developer declares parameters explicitly to be safe against SQL Injection, XSS attacks and similar.

How to ensure that a parameter is safe against specific attacks

To ensure a parameter is safe against SQL Injection attacks, enter following pattern in each field you want to test:

If the content is written into the database exactly like this, the parameter is safe. If the input field is not written to the database and not used in any other way with the database, the parameter is safe anyway.

To ensure a parameter is safe against HTML injection and XSS attacks, enter following pattern in each field you want to test:

Unquoted HTML string injection

Unquoted HTML string injection

Double quoted HTML string injection

XSS injection

If the input field is displayed  in your browser exactly like this, the parameter is safe.

If the input field is not displayed on a browser in the future process, the parameter is safe anyway.

To ensure a parameter is safe against Response Splitting attacks is more tricky.

...but usually not relevant because parameter are almost never written to HTTP headers anyway. Please read the article http://de.wikipedia.org/wiki/HTTP_Response_Splitting for further information. If you know that a parameter is not used in a HTTP header, your parameter is safe.

Conclusion

With the concept of a Parameter Naming Convention, the application developer declares input field types and omits false positives. Of course this concept can be extended very easily and could even provide parameter type informations to outline integers, postal codes etc. to automatically trigger allow rules. And it all works without any framework support, simply by including type information into parameter names.

At least you have to check, that whatever field you added a parameter exception for, the field underneath is clean and ready to process any possible value for the use cases of this field.