Cookie handling and cookie types

HTTP is a stateless protocol, which means that no state or persistent information is stored and each request is executed independently. By using cookies to store and exchange information between requests, session-based HTTP/HTTPS communication can be established, which is both beneficial and convenient for the user experience.

Cookies can be stored temporarily for only a single session, or persistent to be used to keep information between different sessions to allow for a session-spanning experience. The difference between temporary cookies and permanent cookies is, that persistent cookies have an expiry date and are stored on the disk while temporary cookies are kept in memory.

• Temporary and persistent cookies can be used for example to:
• (persistent) store user preferences or the content of a shopping cart.
• (persistent) restore user preferences and language settings.
• (persistent) keep the login status of a user (see also IAM Remember-me functionality).
• (temporary) session cookies.

The web applications and the gateway create dedicated cookies for various purposes:

• Web application cookies from a back-end:
• Temporary cookies e.g. session cookies.
• Persistent cookies e.g. cookies with user preferences, the content of a shopping cart, or the login status of a user (see also IAM Remember-me functionality).

• Gateway cookies:
• Between client and gateway
• Gateway session cookies
• Load balancing cookies
• Between gateway and web application
• Control cookies, created by the web application
• Environment cookies, created by the gateway

In the simplest configuration, without a gateway between the client's browser and the web application, cookies created by the web application are sent with every request between the browser and the web application. This potentially allows attackers to steal and misuse personal cookie information or could lead to other risks like cross-site scripting (XSS) or cross-site-request-forgery (CSRF) attacks.

Airlock Gateway session handling secures the handling of cookies by using a cookie store in a Redis database. In this store, application cookies are kept and a gateway-generated session cookie is linked to these application cookies. The session cookie is used to look up the users' web application cookies and attach them in every request to the back-end application. That way personal and sensitive data will never leave the cookie store/the gateway.

A single Airlock session cookie may be linked to a large number of application cookies in the gateways cookie store. For example, the Airlock session cookie is linked to the web application cookie but may also be linked to an unlimited number of other web application cookies that e.g. may hold the user's default language settings, shopping cart information, remember-me status, and others.

An exemplary Cookie Store look-up table for different AL_SESS cookies may show the following entries:

As we can see, user jdoe from the above graphic has a unique AL_SESS value 657fd545 that is associated with a specific session id. Within this session some cookies are stored like JSESSIONID 7. Other users have their other session and most likely differnt cookies in the cookie store.

By default, cookies set by your application are saved in the current session's cookie store. These internal cookies never reach the user client but are kept and managed by the gateway for each active session.

Note that some cookies such as control cookies, encrypted cookies, and passthrough cookies are not saved in the cookie store.

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

Different from the normal browser behavior, stored cookies are sent to all back-ends. You can enable browser-like handling of cookies with the option Interpret cookie domains in cookie store. When enabled, the gateway will interpret the cookie domain and cookie path information. See also section Interpret cookie domain in cookie store.

• Browser-like handling is based upon the following attributes:
• Cookie origin – This attribute is set automatically to the hostname of the server this cookie originates. 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. In this case, cookies are not only sent to their origin server but also to all other servers in the given domain.
• Cookie path – This attribute is 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 – The port is not utilized.

On a cookie domain match, the domain is part of the cookie domain information of the requested host. For example the domain .foo.net matches host1.foo.net, and host2.other.foo.net.

A cookie path match means that the cookie path is a prefix of the path requested. For example the cookie path /info matches against /info/news.html, and /info/old/deprecated.html.

Some web application functionalities may require bypassing the original cookie from the web application to the client's browser and not keeping them in the cookie store. That means these pass-through cookies are passed from the back-end to the user client and vice versa.

• Possible use cases of pass-through cookies are:
• When cookies are client-side generated.
• When client-side applications need to be able to read the cookie content, like for build-int CSRF protection.

• The options for pass-through cookies are:
• Plain, unencrypted cookies can be configured under Passthrough cookies.
• Encrypted cookies can be configured under Encrypted cookies.

By default, both types of cookie handling are disabled and can be configured on the Basic tab for each mapping. In case some web application functions do not work as expected, consult the gateways log messages to find out if and which cookies must be bypassed and change the gateway configuration accordingly.

If pass-through cookies must be configured, encrypted cookies should be preferred over plain cookies. It is more secure and reduces the attack vector. Encryption should be configured to store all application cookies types with a long-living information payload where the client logic does not read and modify its data. These typically are persistent cookies that carry user preferences like the user's country or language and must therefore live longer than the gateway session.

Note that in pass-through cookies, the cookie domain is modified according to the corresponding settings in the virtual host. Each cookie matching the configured regular expression will be sent through the gateway to the user client. These cookies are accepted by the gateway and sent without changes to the back-end.

• If pass-through cookies is enabled, cookie attributes can be modified by the gateway using Response Actions. Possible reasons for cookie manipulation may be:
• Asymmetric mappings, where the cookie path needs correction.
• Security attribute like the HTTP Only or Secure flag that need to be adapted. Either to increase the security or that the web application works in front of the gateway.

From clientside Airlock Gateway 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.

• Internal links:
• Control API
• Cookie security attributes
• Environment cookies
• Handling of special headers
• Section – Cookies and (CSRF) Tokens
• Section – Application Cookies