Prevent Session Hijacking with HTTP Client Fingerprints

Since release 4.1-10.28,  Airlock is able to detect and prevent session-hijacking attempts. This feature is called HTTP Client Fingerprinting and is disabled by default. It logs information about session hijacking attempts and informs the backend-servers by setting a cookie.

This article explains the concepts of the client fingerprint mechanism and provides insights to customize its configuration. Please note that enabling feature requires that you fully understand the consequences of your configuration changes.

Basic Concepts

The client fingerprint is applied to each request that passes through  Airlock. Based on defined criteria, the session associated with the request might be "punished" with penalty points. Examples of criteria are SSL session ID change or alternation or a change of the HTTP header order. The sum of the penalty points specifies the severity of the hijacking attempt. Depending on the risk group of a mapping or application, different counter measures can be taken such as logging the event or terminating the session.

Risk Groups

 Airlock comes with five predefined risk groups: Integration, Report, Low, Medium, High. Each risk group defines a threshold for the counter measures that must be exceeded in order to trigger the counter measure. The value -1 indicates that the counter measure should never be executed. By default, each mapping is using the ‘Report’ risk group. The ‘Integration’ risk group is recommended if only logging of ominous requests should be enabled. Report also notifies the backend servers by setting the cookie PREFIX_SESSION_HIJACKING_NOTIFICATION to true if a hijacking attempt was detected. Note: Both the Integration and the Report risk groups neither block the request nor terminate the session. In contrast, Low, Medium and High can prevent session hijacking attempts. They differ only by different thresholds for the counter measures.

Penalty Configurations

A penalty configuration lists the criteria that should be evaluated along with the penalty points that are given if a criterion detects a violation. Currently, each mapping has the “DefaultPenaltyConfiguration” assigned. Note that each criterion may have a different number of penalty points. For example, a change of the HTTP header order is considered more critical than a change of the IP address, thus 250 points are given for the first and only 50 for the latter criterion (according to the example in the Figure below).

Session Criteria

The default settings define a number of criteria that is used in the penalty configuration. A criterion can be seen as a list of session properties and/or nested criteria that need to be evaluated. It defines an operator (AND, OR) and a status that must be reached. Using the AND operator, all elements of the list must evaluate to true and conversely, using the OR operator, at least one must evaluate to true. For example:

SessionEvaluationCriterionName0 "exampleCriterion"
SessionEvaluationCriterionOperator0 "AND"
SessionEvaluationCriterionItem0.0 "ipProperty24"
SessionEvaluationCriterionItem0.1 "defaultHeaderValues"
SessionEvaluationCriterionStatus0.0 "change"

The criterion evaluates to true if both the ipProperty24 and the defaultHeaderValues change. If using “OR”, the criterion is satisfied if either ipProperty24 or defaultHeaderValues or both change.

Criteria States

As seen in the previous example, a state can be defined that must be satisfied when examining a session property. The available states are: constant, change, alternation, new, absent, empty:

Constant: a property (e.g. a header value or IP address) is constant over time
Change: a property changed its value at least once over time
Alternation: a property changed its value from X to Y and later switched back to X.
New: the first time that a property appears (e.g. a new header)
Absent: a property was previously present and is now missing
Empty: the value of a property is empty

Session Property

As explained, a criterion operates on a list of nested criteria or session properties. A session has several properties such as an IP address, an SSL session ID, HTTP headers and the order of HTTP headers. The anti session-hijacking mechanism will examine those properties depending on the configuration. A session property has a type (IP, SSL_SESSION_ID, HEADER, HEADER_ORDER) and 0-2 custom fields. For example, the IP property must define a netmask while the HEADER and HEADER_ORDER property define a pattern for the header names that are considered and a flag to invert the pattern or not.

How penalty points are accumulated

Basically, every time a criterion matches, the associated number of penalty points is counted. However, it may not be clear how many points will be given if a criterion previously matched, but does not for the current request.

Let us consider an example where an IP address initially has the value 81.117.130.77. If the IP address changes, 50 penalty points are given and additional 50 points are added for an alternating address (see example above).

Assume that suddenly, the IP address changes from 81.117.130.77 to 99.117.111.203, which will be punished with 50 penalty points. The next request still contains the IP 99.117.111.203. Should now zero points be counted? The answer is that the state of a property is stored in the session. This means that even if the state of the IP address might never change again, the IP criterion will always yield 50 penalty points. Now assume that the IP changes to 131.99.88.123. Should 100 points be given since there were two changes? The answer is that the number of points is still 50 – it does not matter how many times the IP address changes. As a last step, the IP alternates back to 99.117.111.203. The number of points will then be 100, 50 because it changed plus 50 for the alternation.

A mapping using the default “Report” risk group logs and notifies the backend on changes and alternations of an IP address (cf. the risk group table graphic above). Considering a mapping that is configured to use the “Medium” risk group, the backend is only notified if the IP address changed and alternated. If only IP address changes occur (but no alternation), the “Medium” risk group just logs those incidents without notifying the backend.

Enabling HTTP Client Fingerprinting

HTTP Client Fingerprinting must be explicitly enabled in  Airlock using the following steps:

• Login to Airlock Configuration Center
• Copy the following lines from "Expert Settings -> Security Gate -> link: default settings file"

# GLOBALLY ENABLE OR DISABLE CLIENT FINGERPRINTING
#
SecurityGateway * EnableClientFingerprinting            "FALSE"

• Paste this setting into "Expert Settings -> Security Gate" textarea and change the value to TRUE.

# GLOBALLY ENABLE OR DISABLE CLIENT FINGERPRINTING
#
SecurityGateway * EnableClientFingerprinting            "TRUE"

• To make this the changes effective, you have to activate your configuration over Control Center "Activate -> Activate"

After those steps, HTTP Client Fingerprinting is enabled for all mappings using the risk group "Report" and the penalty configuration "DefaultPenaltyConfiguration" as explained in the previous sections.

Configuration

All mappings belong by default to risk group "Report". This means after activating HTTP Client Fingerprinting no requests are blocked and no  sessions are terminated. If you wish an other risk group for a specific mapping you have to follow the steps below:

• Login to Airlock Configuration Center
• Copy the following lines from "Expert Settings -> Security Gate -> link: default settings file"

SecurityGateway * Mapping.<YOUR_MAPPING_NAME>.ClientFingerprinting.RiskGroup "Report"

• Paste this setting into "Expert Settings -> Security Gate" textarea and change the value to your needs. For example to Medium.

SecurityGateway * Mapping.<YOUR_MAPPING_NAME>.ClientFingerprinting.RiskGroup "Medium"

• To make this the changes effective, you have to activate your configuration over Control Center "Activate -> Activate"

Default Configuration

The default configuration for HTTP Client Fingerprinting can be found in Configuration Center under "Expert Settings -> Security Gate -> link: default settings file". The easiest way to find the settings is searching for "finger".

One of the first settings enables/disables client fingerprinting

# GLOBALLY ENABLE OR DISABLE CLIENT FINGERPRINTING
#
SecurityGateway * EnableClientFingerprinting "FALSE"

Somewhere in the middle of the configuration file you find a sections you can find further HTTP Client fingerprinting settings

#########################
# CLIENT FINGERPRINTING #
#########################
# Client fingerprinting - Session Properties
#
# Define which properties of a session should be examined
#
SecurityGateway * SessionPropertyName0 "ipProperty24"
...
...
...
# Client fingerprinting - Evaluation Criterias
#
# Define which properties should be tested regarding a criteria (like CHANGE, ALTERNATION, ...)
#
SecurityGateway * SessionEvaluationCriterionName0 "ip24Change
...
...
...
# Client fingerprinting - Penalty Configuration
#
# Define how many points are given for a matching criteria
#
SecurityGateway * PenaltyConfigurationName0 "DefaultPenaltyConfiguration"
...
...
...
# Client fingerprinting - Risk Group
# Define the level to control which actions should be taken given a certain amount of points
#
SecurityGateway * SessionHijackingRiskGroupName0 "Integration"
...
...
...

Finally in the mapping configuration you can see which RiskGroup and PenaltyConfiguration is applied by default.

SecurityGateway * Mapping.<MAPPING_NAME>.ClientFingerprinting.RiskGroup "Report"
SecurityGateway * Mapping.<MAPPING_NAME>.ClientFingerprinting.PenaltyConfiguration "DefaultPenaltyConfiguration"Whenever you want settings differ to defaults you have to copy the default settings (whole line) into "Expert Settings -> Security Gate"  textarea. To enable your custom settings you need to activate your changes afterwards.