Deny rule exceptions

Airlock Gateway 's allow definition of fine-grained exceptions for all request attributes. Deny rule exceptions can be defined for individual rules or for entire deny rule groups. Defining an exception for a group has the same effect as defining the exception for each rule of the group individually.

For exceptions to take effect, the following conditions must hold:

  • The deny rule for which an exception is defined must block a request.
  • Any of the relevant exceptions must match. Multiple exceptions are linked with a logical OR operation.
  • For an individual exception to match, all exception attributes must be matched. Attributes within an exception are linked with a logical AND operation.

Be as specific as possible when defining exceptions. For instance, adding an exception for content type "application/pdf" may allow bypassing a deny rule simply by adding a header to requests! Whether or not the content is actually interpreted as a PDF file depends on the application and cannot be controlled by Airlock Gateway .

Surrounding conditions for exceptions to take effect

In order to unblock a blocked request, some additional conditions must hold.

Only blocked headers and parameters are considered

When a request is blocked by a deny rule, all non-matching headers and parameters are stripped away for further exception handling. That is, the blocked request is internally reduced to its "bad" headers and parameters. This implies that exceptions cannot unblock requests based on headers and parameters that were not actually blocked by the deny rule.

The reason for this behavior is a simple security consideration. If all headers/parameters were considered in exceptions, an attacker could simply unblock an attack request by adding an additional header/parameter for which an exception exists. In that case, the request would be unblocked even though the exception was not meant to allow list the header/parameter containing the actual attack.

Exceptions may collectively unblock parameters (or headers)

In case there are blocked parameters all exceptions collectively must unblock all blocked parameters for the request to pass.

For example, if a request contains two blocked parameters, the request may be unblocked by:

  • an exception matching both blocked parameters
  • two exceptions unblocking a single parameter each
  • an exception to the used path (see below)

The same logic is used for unblocking headers.

Name and value of headers/parameters are linked

Names and values of parameters/headers in exceptions are linked. That is, if both name and value patterns are defined in an exception, the exception only takes effect if both patterns match on the same parameter/header.

Exceptions on path or HTTP method

Exceptions to path or HTTP method are treated differently. They do unblock a request regardless of whether it was blocked by this attribute or not.

This behavior is useful for implementing use-cases as:

  • unblock administration network
  • the form /mypath/form1 must not block mobile clients, since the mobile version of the page uses the same path

Examples

Excluding certain values for a specific parameter

Assume your company is hosting an online tool for reporting security incidents. The report form needs to collect incident information and must therefore allow certain file names to pass that would trigger file inclusion deny rule: 

Exception:
Parameter name:  ^affected-files$
Value: /etc/(crontab|group|passwd)

Excluding a parameter on a specific URL

To exclude parameter comment1 only on a single URL and not for the entire mapping, combine the two conditions in a single exception: 

Exception:
Path:            ^/register/form1$
Parameter name:  ^comment1$

Excluding URL-parameter pairs

If the comment parameter needs to be excluded on yet another form, you can either add a second exception or include the second URL in the path condition of the first exception. However, if you want to exclude a different parameter comment2 on a different form, make sure to use a second exception to avoid excluding all combinations of parameters and URLs (e.g. comment2 on /register/form1): 

Exception 1:
Path:            ^/register/form1$
Parameter name:  ^comment1$

Exception 2:
Path:            ^/register/form2$
Parameter name:  ^comment2$

Exception 3:
Path:            ^/register/form3$
Parameter name:  ^comment3$

Testing the new form from mobile clients

To disable a deny rule for developers accessing the new registration pagewith iPhone clients: 

Exception:Path:            ^/register/form$
Header Name:     ^User-Agent$               Value: iPhone