Sensitive File Content
Certain files in the Intershop Commerce Management installation contain sensitive information like database passwords or an encryption pass phrase. Unfortunately, sensitive information in files cannot be completely avoided. For ICM sensitive data is stored in:
- <eserver>/share/system/config/cluster/ orm.properties
- intershop.jdbc.user=<database user name>
- intershop.jdbc.password= <database user password>
- intershop.encryption.passphrase=<encryption and decryption pass phrase>
- unique identifier of the Enfinity Suite cluster; automatically generated at server startup if the file does not exist; used to sign session identifiers
- Private key file for SSL server certificates
- SSH keys and pass-phrases for communication with the reporting server (created by “ant ssh_keygen”)
- Java security configuration
- SSL configuration for the Tomcat Cluster Management
Keep the number of people with access to the file system as small as possible.
Sensitive information, for example the database login and password or the encryption pass phrases are shown on the Properties page in the Application Server section of the SMC. The setting intershop.cartridges.<cartridge name>.sensitiveProperties specifies which server properties must not be put in the pipeline dictionary and thus will not be shown in the SMC. Depending on Intershop version this property is located in the configuration file of different cartridges:
Developers must ensure that any sensitive data (user credentials, credit card data, etc.) is securely transmitted by using HTTPS. Secure HTTP is even important for SEO as Google is penalizing websites which aren’t using HTTPS across the board.
HTML Form Transmission
Another very important thing is the transmission of HTML forms and it’s values. Even if HTTPS is used for all requests it is possible that important information from customers are written as clear text into log files for instance. A common mistake is to use GET requests for form transmission. Here is an made up example as it could be written into the Apache Web Server access logs:
127.0.0.1 - - [01/Jan/2017:00:00:00 +0100] "GET /INTERSHOP/web/WFS/inSPIRED-inTRONICS-Site/en_US/-/USD/ViewLogin-Dispatch?Login=some_user_logon&Password=some_user_password HTTP/1.1" 200 12965
This is what the form in ISML eventually looks like:
<isform action="#URLEX(SecureURL,'',Action('ViewLogin-Dispatch'))#" method="get">
To avoid this behaviour is pretty simple just change the transmission of the form from GET to POST:
<isform action="#URLEX(SecureURL,'',Action('ViewLogin-Dispatch'))#" method="post">
The same log entry then would look like this:
127.0.0.1 - - [01/Jan/2017:00:00:00 +0100] "POST /INTERSHOP/web/WFS/inSPIRED-inTRONICS-Site/en_US/-/USD/ViewLogin-Dispatch HTTP/1.1" 200 13695
As standard output doesn’t log HTTP content from the request body there is no need to worry about sensitive data to be logged into log files.
The standard distributions of Intershop already use encryption when storing sensitive data into the database. For the storage of additional sensitive information in the database or for changed implementations of the standard mechanism,Intershop provides the Java class
com.intershop.beehive.foundation.crypt.EncryptionUtils for encrypting and decrypting those data.
Details on Class com.intershop.beehive.foundation.crypt.EncryptionUtils
This class provides methods to encrypt and decrypt data. The pass phrases used to encrypt and decrypt text must at least be 5 characters long.
encrypt(char,String)encrypt the given plain text with the given password phrase using a password based PBEWithMD5AndTripleDES algorithm. The resulting cipher text contains the used crypto algorithm in a readable form as prefix:
EncryptionUtils#encrypt(char,String,String)encrypt the given plain text with the given password phrase using the specified encryption algorithm. The resulting cipher text contains the used crypto algorithm in a readable form as prefix: algorithm:[cipher_text].
If the algorithm is implemented by a third party provider, instead of being part of the set of algorithms delivered by the JRE, then this provider must be registered in the java.security file of the used JVM. The following entry declares a provider, and specifies its preference order n. The preference order is the order in which providers are searched for requested algorithms (when no specific provider is requested).:
security.provider.n = masterClassName
Note that specific algorithm, like PBEWithMD5AndTripleDES, might be implemented by more than one security provider registered in the java.security file of the JVM. In this case, the
EncryptionUtils#encrypt(byte,String) and the
encrypt(char,String) method use the requested algorithm implementation by the provider that is found at first in the preference order. This fact makes it eventually necessary, to change the preference order of registered security providers to get the desired one.
decrypt(char,String)decrypt the given cipher text with the given password phrase using the algorithm that is specified in the prefix of the cipher text: algorithm:[cipher_text].
EncryptionUtils#decrypt(char,String,String)decrypt the given cipher text with the given password phrase using the specified encryption algorithm.
If the cipher text contains the algorithm as prefix then this one will be used for decryption and the
algorithm parameter will be ignored.
encrypt(char,String) as well as
decrypt(char,String) encode the delivered
passPhrase before using this one for any cryptographic operation with Base64, to ensure the uniqueness of that passphrase across all code pages.
Co-Authors: Thomas Bergmann, Nils Breitmann and Intershop Consulting Stuttgart