You are here

Airlock Adaps: The Next Step for Dynamic Whitelisting

The Airlock team has developed an innovative dynamic protection technology (patent pending) that will set new trends in web application security. Read why this approach will solve most security problems of today's web application environments.

The challenge of meaningful and efficient filter protection

Many previously available application security technologies focus on blacklist filter (negative security model) to protect Web applications by recognizing known malicious patterns. Although blacklist filtering is very important to prevent known attacks, they do not suffice. Today, most application level attacks are targeted and criminally motivated. The Web application provider can not rely on already known patterns exclusively as protection against targeted attacks. The opposite is the case: Most Web applications which rely on blacklist filtering for protection can be successfully exploited in a short period of time by knowledgeable hackers, usually by direct and targeted reverse engineering and penetration.

Whitelist approach (positive security model)

The much more appealing approach would be to block everything that is not specifically recognized as valid. Such an approach is called whitelist filtering. Everything that is not explicitly allowed is forbidden. Whitelist filtering is for example simple to implement when a clear schema or an interface description is available. SOAP/XML Web services, for example, can implement whitelist filtering by validating all requests and data against the defined schema of the service. For Web applications in general, there is no schema or comprehensive interface documentation available that could be enforced. That is one of the biggest challenges encountered when securing Web applications.

How to implement whitelist filtering for Web applications

Implementing whitelist filtering for Web applications means to enforce the valid usage throughout the whole Web application. For example, whitelist filtering could require

  • user identification if possible (preceding authentication)
  • accept only valid URLs
  • valid parameters in URLs
  • length restrictions according to input field meta data
  • protection of predefined values (HTML selection lists, hidden fields, radio buttons, etc.)
  • enforcement of input types and input value ranges

Although the goals and criteria of whitelist filtering are clear, it is not that simple to implement a mechanism that provides the desired benefits. Different technology approaches are available on the market to implement whitelist filtering:

  • Manual whitelist rule configuration --> static
  • Rule generator --> static
  • Learning mode --> static
  • Airlock dynamic whitelist --> dynamic!

It is definitely possible to define manual filter rules in order to implement whitelisting. For example, a rule could be defined which specifies the valid URL, its parameters and all possible value types and value ranges for the parameters of that specific URL. Such a rule would be a static whitelist rule. Why static? Static because if the application changes only a little bit (URL changes, parameter changes, value changes), the whitelist rule is invalidated. Even worse, it is not possible to protect today's dynamic web applications with static whitelist rules: The content of a web application may depend on a user profile, on the date or time or any other criteria that can never be considered in a static filter rule. User A may see a different Web form than user B, for example.

Some products try to work around this issue by using what is generally known as a Rule Generator or Learning Mode. But in the end, these also produce only static filter rules. Practical experience in medium to large organizations has shown that static whitelist filter rules cannot be maintained efficiently and effectively over time.

For very exposed parts of a Web application, such as the login page, a registration form or a search form, it may be useful to define a very strict static whitelist rule. But static whitelist rules are not appropriate to protect the whole business logic of a dynamic Web application. For that, we need real dynamic whitelist filter technologies.

Dynamic whitelist filtering in Airlock

Airlock already contains several real dynamic whitelist filtering technologies which proof their effectiveness in numerous productive installations:

URL Encryption

URLs (links and embedded resources in HTML) are automatically recognized and encrypted when the application delivers HTML content to the client browser. The strong encryption can be applied with a node-based or session-based key. URL encryption is truely dynamic, since it always protects the data as it is generated by the Web application. No static rules or configurations are required. Sometimes it is not possible to cover 100% of the URL spectrum with URL encryption because of client-side generated URLs. But even if only 60-80% of the whole application spectrum can be covered with URL encryption, the security level is significantly increased without the need for managing hundreds or thousands of static filter rules.

Cookie Protection

Application cookies are cryptographically encrypted and digitally signed. Or alternatively they can be stored within Airlock's secure session context and never even be delivered to the client browser. In both cases, the cookie protection is truely dynamic and does not require static rules or configuration efforts.

Smart Form Protection

Beyond the URLs embedded in HTML and CSS resources, especiall HTML forms and user inputs are a dangerous attack vector. Airlock also provides truely dynamic whitelist filtering in this area by validating the value of hidden fields, the length of user inputs, the value of selections or many other HTML form input criteria against a digital signature that Airlock dynamically embeds in the HTML code. Instead of having to create hundreds or thousands of static rules, the declaration of what is valid directly comes from the application, in the HTML code, and is interpreted and protected by Airlock.

Advanced Declarative Application Security (ADAPS)

URL encryption, cookie protection and smart form protection work on the standard HTML 4 basis. The Airlock team has developed an advanced declarative application security technology that makes dynamic whitelist filtering even more flexible and powerful. The concept behind the technology introduces a clear separation between security information declaration and enforcement. Instead of desperately trying to reproduce the application level know-how about input fields, value types or value data ranges into a Web Application Firewall configuration, this new technology empowers application developers to be responsible for the declaration of what the application expects and what are valid input values. However, the application is not the best location alone to implement security enforcement, because it might be already too late, or the application developer had no chance to prevent an attack that was only discovered after the application was online for a couple of months (and the developer working on a different project by now).  Therefore, the new declarative application security technology of Airlock makes it possible to embed detailed security information declarations inside HTML, going far beyond the limitations of standard HTML 4. For HTML 4-based applications, that can be achieved by embedding special tags into the HTML with the detailed declaration information. For future applications based on HTML 5, Airlock will interpret and enforce the comprehensive declarative information of the X-* standards (e.g. in X-Forms) in order to implement dynamic whitelist filtering.

For more information see article ADAPS configuration which provides a whitepaper documentation and a user manual.

Conclusion 

ADAPS, the new declarative application security of Airlock, not only provides an advanced method for protecting Web applications, but it also solves the biggest operational problems in medium-to-large enterprises: It's often impossible or just too expensive to reproduce the application level know-how into the operation of a Web application firewall. By specifically accepting and pointing out the responsibility of application developers to provide declarative information, the infrastructure operators are relieved from cumbersome enforcement tasks which they can never really fulfill.

Knowledge Base Categories: