Security features apply to communications with the target page, local storage cache, logging levels, data masking, and data blocking.
Removal of vulnerable code
Acoustic has reviewed supported versions of Tealeaf On-Premises to discover any instances of the vulnerable version of log4j. Some Tealeaf On-Premises versions have used log4j v1.x, which is vulnerable to CVE-2021-4104 and CVE-2019-17571. These are moderate vulnerabilities if JMSAppender or SocketServer are configured for use. Tealeaf On-Premises is not configured to use JMSAppender or SocketServer and, therefore, is not currently deemed to be vulnerable. Customers wishing to completely remove the impacted net/SMTPAppender.class, net/SocketAppender.class, net/JMSAppender.class, net/SocketService.class classes from log4j v1.x can do the following:
-
Download log4j-1.2.17.jar from the Downloads page
-
Replace instances of log4j-1.2.17.jar with the downloaded file (see paths below)
-
Restart Tealeaf Extractor and Tealeaf Replay services
Path to replace log4j-1.2.17.jar (v10.2 and prior):
-
<install-directory>/WebSphere/usr/servers/DOMDiffServer/apps/DOMDiffServer.war/WEB-INF/lib/log4j-1.2.17.jar
-
<install-directory>/WebSphere/usr/servers/LTSServer/apps/LTSServer.war/WEB-INF/lib/log4j-1.2.17.jar
Path to replace log4j-1.2.17.jar (v10.3):
-
<installationdirectory>\apache-tomcat\apache\webapps\LTSServer\WEB-INF\lib
-
<installationdirectory>\apache-tomcat\apache\webapps\DOMDiffServer\WEB-INF\lib
Note: If you applied mitigation prior to January 11, 2022, you will need to re-apply mitigation if you want all four classes removed. Prior to January 11, 2022 only the JMSAppender and SocketServer classes were removed from the JAR.
HTTPS communications with target page
Client frameworks provide a configurable means of submitting captured events to the Tealeaf target page by HTTPS.
There is a performance overhead in sending data over HTTPS. The performance impacts depend on the type of application, the network bandwidth, and the network load.
To deploy HTTPS communications, you might deploy any of the provided Tealeaf target pages and configure on the server the directory permissions for HTTPS access.
This table lists what you do to deploy HTTPS communications:
Client Framework | What you do |
---|---|
UI Capture | To configure submitting by HTTPS for AJAX, you must configure the tlsecureurl property for the target page.
No configuration is needed for UI Capture j2. The server-side endpoint can manage both secure and non-secure POSTs. The protocol of the POST is determined by the protocol of the parent page. |
Android Logging | To configure HTTPS submissions, configure the PostMessageUrl property in the TLFConfigurableItems.properties file to use the https:// protocol. |
iOS Logging Framework | To configure HTTPS submissions, configure the PostMessageUrl property in the TealeafBasicConfig.plist file to use the https:// protocol. |
Disable local storage cache
If needed, some client frameworks can be configured to disable the local storage cache, which is used to gather client events for submission to Tealeaf.
During cached operations, if the client framework is unable to connect to the target, events are queued in a local memory buffer. If the buffer fills before the connection is restored, the last event that is stored in the buffer is discarded. This buffer is cleared on restart or power down.
When the local storage cache is disabled, client events are sent as soon as they are detected by the client framework. Since there is a data overhead for submitting a package of events, the data overhead increases when sending a single event per package, which might affect client and network performance.
This table lists what you do to disable the local storage cache:
Client Framework | What you do |
---|---|
UI Capture | For AJAX, the local storage cache size and availability can be configured through the user's browser.
UI Capture j2 does not support cached operations and requires a live connection to the web server to submit POSTs. If a live connection to the web server that hosts the target page is not available, captured UI data is discarded. |
Android Logging | For the Android framework, you can configure local cache settings, including disabling it altogether using the HasToPersistLocalCache setting. |
iOS Logging Framework | For the iOS framework, you can configure local cache settings, including disabling it altogether using the HasToPersistLocalCache setting. |
Data masking
Each client framework enables the masking of sensitive data on the client before it is submitted to Tealeaf. Through configuration, you can identify for the client framework the objects in the monitored application that must be masked. For example, you can indicate that each numeral in a credit card field must be replaced by an X
:
credit_card_num=XXXX-XXXX-XXXX-XXXX
This table lists what you do to configure data masking:
Client Framework | What you do |
---|---|
UI Capture | For AJAX, in the TealeafClientCfg.js file, you can specify the fields to mask with the tlFieldBlock array. JSON message fields can be specified by name, ID, or class name.
For UI Capture j2, use the UIC Configuration Wizard to specify the user input fields to mask. Input fields can be specified by HTML ID, name, CSS class, or any custom attribute. If a live connection to the web server that hosts the target page is not available, captured UI data is discarded. |
Android Logging | Through the TLFConfigurableItems.properties file, you can configure the fields to mask, the masking characters, and other features. |
iOS Logging Framework | Through the TealeafBasicConfig.plist file, you can configure the fields to mask, the masking characters, and other features. |
Data blocking
Data blocking removes all values that are related to the blocked field.
As needed, you can configure the data for individual items to be blocked altogether. If the data in the data masking example was blocked, the submitted item would be:
credit_card_num=
JSON-based values are not stored in name/value format. As a result, the configuration that is required to block JSON-based data is different. In the example below, the value of the textbox (myLoginID
) must be masked:
{
"type": 4,
"offset": 14953,
"screenviewOffset": 14953,
"count": 5,
"fromWeb": true,
"target": {
"id": "qty",
"idType": -1,
"name": "qty",
"tlType": "textBox",
"type": "INPUT",
"subType": "text",
"position": {
"width": 36,
"height": 21,
"relXY": "0.6,0.6"
},
"currState": {
"value": "myLoginID"
},
"isParentLink": false,
"prevState": {
"value": ""
},
"dwell": 1609,
"visitedCount": 1
},
Since this value is stored as the value of a JSON path, you must specify the path that uses a different method of identifying its location in the JSON data.
Client Framework | What you do |
---|---|
UI Capture | For AJAX, data blocking is configured in a similar manner to data masking.
For UI Capture j2 data blocking is configured by specifying identifiers, the identifier type, and the masking properties through the Configuration Wizard. If a live connection to the web server that hosts the target page is not available, captured UI data is discarded. |
Android Logging | The configuration is similar to configuring fields for data blocking. |
iOS Logging Framework | The configuration is similar to configuring fields for data blocking. |