You are here

Best practice to handle Airlock WAF Parameter Exceptions

Affects product: 
Airlock WAF
Affects version(s): 
5.x

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.

For advanced application driven security policy provisioning, please have a look at ADAPS.

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.

Solution

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.

Parameter Naming Convention

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:

PrefixParameter Type Description
alTx_Text input fields

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

Rule Groups
Exception Pattern for Parameter Name
... in Parameter Value
^alTx_

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 the parameter is safe against the specific attacks

To ensure a parameter is safe against SQL Injection attacks:

  • enter text with quotes, hashes etc. in the application form and double check the input in the database. If the content is written into the database like the application developers expected, 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 XSS attacks:

  • enter text with brackets like <, >, {, } etc. in the application form and double check if the input is displayed correctly in the browser. Please note that this text could also be used in another user's browser e.g. by the customer center or the Airlock administrators browser!!
  • 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.

Be aware, that vulnerable parameters are dangerous! Do not exclude parameters from beeing filtered without checking their correct implementation, handling and encoding with the procedures described above.

Conclusion

With this concept, 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.

Knowledge Base Categories: