Cookie Handling

Introduction

Cookies are used to save the state of Web applications. e.g. sessions. When a Web application sets a cookie, the client, the browser, saves it and attaches it to the following requests to that Web application. Cookies should be used carefully, because an attacker could be able to steal cookie information abuse it.

Airlock both uses cookies itself internally and helps you to protect your application's cookies. In this article, we give an overview over the cookies used by Airlock, and show you how to secure the use of cookies in your applications.

Airlock knows the following cookie types:

• Web Application Cookies

• Temporary cookies (e.g. session cookie)
• Persistent cookies (e.g. user preferences, language settings)

•  Airlock Cookies

• Session cookie
• Load balancing cookie
• Environment cookies
• Control cookies

Cookies without  Airlock

Without Airlock, cookies sent by Web applications are saved by the browser and sent back to the origin server with all subsequent requests.

                                  Browser                       Web Application
                                     |                                 |
Application Cookie                   |<------------------------------->|

Cookies with  Airlock

                                  Browser          Airlock       Web Application
                                     |               |                 |
Application Cookie (default)         |               |<--------------->|
Application Cookie (pass-through)    |<------------------------------->|
Application Cookie (encrypted)       |<==============----------------->|
                                     |               |                 |
Airlock Session Cookie               |<------------->|                 |
Airlock Load-balancing Cookie        |<------------->|                 |
Airlock Environment Cookie           |               |---------------->|
Airlock Control Cookie               |               |<----------------|

Environment Cookies

Airlock sends internal information to the back-end using environment cookies.

The name of all environment cookies begins with the cookie prefix. The environment cookie prefix is set up in the Airlock Configuration Center under "Expert Settings" (see Configuration Center online help, section "Airlock Back-End Control-API"). Environment cookies must be enabled in the mapping configuration (see Configuration Center online help, section "Mappings").

Example (request header sent from Airlock to application):

Cookie: AL_ENV_REMOTE_ADDR=213.144.135.98

For a complete list of environment cookies, consult the Configuration Center online help, section "Airlock Back-End Control-API".

Control cookie

With the control cookie, your application is able to execute "Control API" commands. This powerful feature must be enabled in the Mapping configuration. The cookie name of the control cookie is set to "AL_CONTROL" by default. The control cookie name can be changed in the Configuration Center under "Expert Settings".

Example: Your application may terminate the current session by setting the following cookie:

AL_CONTROL=SESSION%3DTERMINATE

Encrypted cookies vs. the Cookie Store

To protect your application from cookie manipulation, you can make use of either encrypted cookies or the cookie store.

Encrypted cookies

Airlock recognizes encrypted cookies with the Encrypted cookie regular expression setting in the Mapping settings. All cookies with a matching cookie name will be encrypted before being sent to the browser. Incoming encrypted cookies are automatically decrypted before being sent to the Web application. Now, an attacker is no longer able to read nor manipulate the contents of your cookies.

You should define an encrypted cookie regular expression for all persistent application cookies. These cookies typically contain user preferences (like the user's country or language) and must therefore live longer than the Airlock session.

The Cookie Store

Airlock keeps a Cookie Store for each active session. All cookies* set by your application are saved in the current session's Cookie Store. These cookies never reach the user client but are kept and managed by Airlock.

* Control cookies, encrypted cookies and passthrough cookies are not saved in the Cookie Store.

To avoid multiple storage of the same cookie, Airlock compares the cookie name, the cookie domain and the cookie path. Two cookies are considered to be the same if all three values are equal.

By default, all stored cookies are sent to all back-end servers. This is not the way a browser handles cookies. You can enable a browser-like handling of cookies with the option Interpret cookie domains in cookie store. Beginning with version 4.1.-10.45, this checkbox also enables the interpretation of the cookie path.

Interpretation of the cookie attributes

Enabling Interpret cookie domains lets Airlock handle cookies with a similar logic to browsers.

• Cookie origin
  This attribute is set automatically to the hostname of the server this cookie originates from.
  If this is the only attribute set, the cookie is sent with requests to its origin server.

• Cookie domain
  This attribute may be set by the Web application. It defines the domain within which this cookie is valid.
  Cookie are then not only sent to its origin server but also to all other servers in the given domain.

• Cookie path
  This attribute is also set by the Web application and restricts the use of this cookie to the given path.
  Assuming the cookie would be sent because of the origin and domain values, it might be retained when the path attribute doesn't match the request's path.
• Cookie port is currently ignored.

Domain match means that the cookie domain is part of the domain of the requested host.
e.g. The domain .foo.net matches against hosts: host1.foo.net, host2.other.foo.net

Path match means that the cookie path is a prefix of the path requested.
e.g. The cookie path /info matches against /info/news.html, /info/old/deprecated.html

Passthrough cookies

In some cases it is nessesary to pass cookies to the user client without encryption. Such cookies must be configured as "passthrough" cookies. They are passed from the back-end to the user client and vice versa. In passthrough cookies, the cookie domain is modified according to the corresponding settings in the virtual host. You can define passthrough cookies by entering a Passthrough cookie regular expression in the Mapping configuration. Each cookie matching the configured regular expression will be sent through Airlock to the user client. These cookies are also accepted and sent without changes through Airlock to the back-end.

Possible use cases of passthrough cookies are:

• Client-side generated cookies
• Client-side applications need to be able to read the cookie content

From clientside Airlock accepts only its own cookies for session handling and load-balancing as well as passthrough cookies and encrypted cookies. All other cookies are rated as unexpected and will be discarded.