Introduction

This guide should give you an overview of what can be done to tighten an installation of Intershop Commerce Management in regards to security and data protection.

Prevention of Injections

To avoid SQL injection vulnerabilities only prepared statements with parameter binding should be used:

String custname = request.getParameter("customerName"); 
String query = "SELECT account_balance FROM user_data WHERE user_name = ?"; 
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, custname); 
ResultSet results = pstmt.executeQuery();

Intershop Specifics - ORM Layer

The best way to avoid SQL injection vulnerabilities is to use the CAPI interfaces created by the ORM layer and to avoid the execution of getObjectsBySQLWhere()/getObjectsBySQLJoin(). This can be achieved by defining alternate object keys and relations in the EDL as shown in the following example:

namespace com.intershop.component.customer.orm.internal.^orm
{
	orm class CustomerPO extends ExtensibleObjectPO table "CUSTOMER"
	{
		alternate key (customerNo, domainID); 
		
		attribute customerNo: string<256> required searchable;
		attribute customerTypeID: string<256> required;
		attribute approvalStatus: int;
		attribute profileID: uuid required;
		
		relation customerBasicProfileAssignments: CustomerBasicProfileAssignmentPO[0..n] inverse customer;
		relation customerCompanyProfile: CompanyProfilePO[0..1] inverse companyCustomer;
		
		dependency customerBasicProfile: BasicProfilePO
		{
			foreign key(profileID);
		}
	}
}

In this example the DomainId and CustomerNo form an alternate (semantic) key for the CustomerPO object. With the corresponding object factory it is possible to look up with plain Java, just as getting the related company profile:

...
 
final CustomerPOAlternateKey customerKey = new CustomerPOAlternateKey(customerNo, currentDomain);
final CustomerPO customer = customerPOFactory.getObjectByAlternateKey(customerKey);
 
final CompanyProfilePO companyProfile = customer.getCustomerCompanyProfile();
 
...

In case this is not sufficient and still the getObjectsBySQLWhere()/getObjectsBySQLJoin() need to be used, the object factory's API with parameter binding should be used:

Collection<Foo> foos = fooFactory.getObjectsBySQLWhere("name=?", new Object[]{"bla"});
 
Collection<Bar> bars = barFactory.getObjectsBySQLJoin("Foo f", "this.uuid=f.barID and this.name=?", new Object[]{"bla"});

For more details please refer to Concept - ORM Layer and Cookbook - ORM Layer.

Intershop Specifics - Query Framework

When using the file base query framework from Intershop, make sure only the default bind parameter processing is used for parameter assignment:

<template-variable value="ProductTable" />

or

<template-variable value="ProductTable" processing="bind"/>

But do not use text as processing type:

<template-variable value="ProductTable" processing="text"/>

For more details please see the Reference - Query File Syntax (valid to 7.9).

Authentication and Session Management

For additional information please refer to Overview - Administration and Configuration and its subsequent documents.

User Credentials & Passwords

By default Intershop used to have a cryptographic one-way hash function (MD5) to encrypt the users password. As MD5 is known to vulnerabilities now PBKDF2 (Password-Based Key Derivation Function 2) is used instead. Users passwords are migrated on the fly when users log in again.

Session Management via Cookies

To reduce the risk of spreading session IDs with an URL, it is advised to use browser cookies, CookieOnly, for session handling and session management. For Intershop Commerce Management (ICM) the session handling can be configured under $IS_HOME/share/system/config/cluster/webadapter.properties:

session.tracking.mode=URLOnly|CookieOnly|CookiePreferred|CookieOverridesURL

In recent versions, since Intershop 7.4 CI, this has changed and the tracking mode is now set to CookieOnly per default and any other option is obsolete.

Web Adapter Session Handling

Web based applications use session IDs (SIDs) to overcome the limitations of the HTTP. As a stateless protocol, HTTP needs a session ID to assign certain activities to a specific user. Each user entering a site for the first time starts a new session and gets a unique session ID. From that point, this SID will be used in all subsequent requests. Depending on the lifetime value specified for a session, the IDs remain valid for a few minutes, hours, or even days.

Session Cookie Settings

You can define how the session tracking cookies are set in the client. To this end, the webadapter.properties file includes the two settings:

session.SIDCookie[.<site>] = <Set-Cookie>
session.PGIDCookie[.<site>] = <Set-Cookie>

where session.SIDCookie defines the SID cookie generation, and session.PGIDCookie defines the PGID cookie generation. The default values are:

#session.SIDCookie = Set-Cookie: sid=%v; Path=/; Version=1
#session.PGIDCookie = Set-Cookie: pgid=%v; Path=/; Version=1

The placeholder %v is to be used "as is" as the actual SID or PGID cookie value. Another placeholder, %s, expands to the request's site name (or an empty string), which is useful in the PGID name definition.
For detailed information about the <Set-Cookie> syntax, refer to RFC 2109 (www.ietf.org/rfc/rfc2109.txt).

Separate Authentication State

The authentication state is separated from the session ID. An attacker knowing an SID is not allowed to perform critical operations, such as ordering and account management. This is implemented with a secure cookie SecureSessionID: It is stored at the client with a successful login and it must be presented to the server for all subsequent critical operations. This cookie has the "Secure" attribute set and thus is transmitted only via 'secure connections', typically HTTPS. It will never be transferred in unencrypted form. See RFC 2109 for details. This feature can be controlled at $IS_HOME/share/system/config/cluster/appserver.properties:

intershop.session.securetoken.cookie.domain=
intershop.session.securetoken.cookie.path=/
intershop.session.securetoken.cookie.comment=INTERSHOP Secure Token
intershop.session.securetoken.cookie.maxage=-1

Session Timeout

To reduce the risk of misuse, reduce the period of time an SID remains valid. This can only be done by setting a hard limit for the lifetime of SIDs, and therefore implicitly for the lifetime of application server sessions. If the Intershop system receives an HTTP request containing an SID that reached the end of its lifetime, a new SID is created and assigned to the client. The hard limit for the SID lifetime can be configured at $IS_HOME/share/system/config/cluster/webadapter.properties:

session.ttl=<time in seconds> 

Besides this "hard" SID timeout, there is also a "soft" timeout for the lifetime of an application server session. The related session timeout counter restarts with each request. If the application server does not receive a request for this session within the session timeout interval, the session state at the application server is discarded. The SID itself remains valid. The next application server request with this SID would create a new session at the application server. Configure the session timeout at $IS_HOME/share/system/config/cluster/appserver.properties:

intershop.session.TimeOut=<time in minutes> 

Bind SID to User Agent

Intershop can be configured to bind SIDs to a particular user agent. This is done by including the contents of the HTTP header field "User-Agent" into the MD5 hash of the generated SID. SIDs in URLs are then only valid if they are sent from a client computer whose web browser and operating system version match that of the web client that started the session. This behavior can be configured at $IS_HOME/share/system/config/cluster/webadapter.properties:

session.bindToUserAgent=true  

The default value is 'false'.

Avoid Cross-Site Scripting (XSS)

As the base for XSS vulnerability is the non-encoded integration of untrusted input into dynamically created web pages, it is necessary to make sure that any input is encoded when being displayed. With Intershop Commerce Management (ICM) this is being achieved by using the <isprint> tag or the stringToHtml() function:

<isprint value="#Product:Name#">
#stringToHtml(Product:Name)#
<istext key="welcome.message" param0="#stringToHtml(User:Name)#" encoding="on">

So for example encoding for JavaScript in a <script> block would look like this:

<script type="text/javascript">
	window.parent.location.href = '<isprint value="#URL(Action('ViewDashboard-Show'), Parameter('DashboardID', DashboardBO:ID))#" encoding="javascript">';
</script>

Also multiple encodings can be applied by passing a list of encoding identifiers (e.g., <isprint value"#SomeContent# encoding="xml,javascript">). Even own encoding handlers can be registered and used for custom encoding requirements.

Sanitizing Untrusted Input

An additional countermeasure for preventing XSS vulnerability is the sanitizing of untrusted input, which means that input is validated and/or HTML formatted text cleaned. Since Intershop 7.4 a webform validator is available for XSS.

Persistent XSS Protection - XSS Form Validator

A new webform validator has been introduced for preventing XSS attacks. It uses a library provided by The Open Web Application Security Project. XSS validation can be used specifically per parameter by referring to the respective validator, GlobalValidators-xss. Additionally, it is possible to have all webform parameters/fields of type string validated automatically at application level by setting the configuration parameter webform.validation.xss

Template API Checker

ICM includes a template API checker at $IS_HOME/tools/api_checker which is capable of identifying potential XSS vulnerabilities.

Prohibit Insecure Direct Object References

Indirect Object References

Sensitive parameters in URLs should be encrypted or processed in a way that the range of possible values is much larger than the range of really used values. The probability to guess a valid value would drop considerably. An example is the usage of product UUIDs instead of product SKUs (stock keeping units).

Access Check

Ideally the access to (sensitive) data is done at the lowest, the object level, instead of securing only (certain) paths to an object.
The Intershop pipeline request processing allows ACL permission check (see also section Missing Function Level Access Control). A user needs in a specific context (organization/channel) permission for the executed action. In case of an indirect object access the implementation needs to be aware of resolved objects of another context.

• Resolving UUID from request (verify the domainid of the returned object)
• Search results (add domainid as additional query parameter)
• 1 to n relation (returned objects could be from other contexts, sometimes)

Example

For example an URL might exist that displays the basket of the current user, e.g., https://127.0.0.1/INTERSHOP/web/WFS/PrimeTech-PrimeTechSpecials-Site/en_US/-/USD/ViewCart-View?BasketID=12345. Somebody might try to change the value of the BasketID parameter to display the basket of somebody else. So it is necessary to check whether the basket can be accessed with the current context (here by the current user) as it is done at the GetBasketByID pipelet:

...
   Basket basket = basketMgr.resolveBasketFromID(basketID);
   if (basket == null) 
   {
       return PIPELET_NEXT;
   }
   //only baskets from current user are allowed
   if (currentUserOnly && !basket.getUser().equals(user))
   {
       pipelineDictionary.put("ERROR_User", "true");
       return PIPELET_ERROR;
   }
...

Prevent Security Misconfiguration

Application Updates

Regular product updates, hotfixes and patches are released for Intershop products fixing also potential security issues.
The support department informs about important security updates via newsletter "security bulletin". Updates and patches are announced at the support web page (https://support.intershop.com/)

Verify Default Settings

Intershop is being delivered with a standard configuration setup, which includes standard passwords for system accounts, as well as demo stores. Some settings of this standard configuration need to be changed/adapted or at least need to be verified.

Intershop 7

Database

1. Change the database passwords.
   The Knowledge Base article Using DBCA templates for creating a database from the scratch describes how to create a database instance suitable for your Intershop 7. As soon as your system is about to go live, contact your Oracle Database Administrator to change these passwords. Afterwards, you have to update the passwords in your orm.properties located in $IS_share/system/config/cluster.
   intershop.jdbc.password=<NewIntershopPassword>

2. Back up the database.
   Make a backup of your database content before going live to preserve the original state of your database. Refer to your Oracle manuals, to the Knowledge Base article Backup Strategy for Oracle Databases or contact your database administrator for more information.

3. Set Oracle to archive mode.
   Setting the Oracle server to archive mode is essential to enable the recovery of the database in the case of a system server crash, for example a disk crash. Read: Setting the Oracle Server to Archive Mode.

4. Consider Oracle Tuning Measures.
   Tuning is strongly recommended, depending on your own database setup. Thus we just provide the requirements for the Intershop application, and leave this topic in the responsibility of your database administrator.

Web Server / Web Adapter

1. Enable page cache.
   Enabling page caching is recommended to decrease the response time of the Intershop Application. It decreases the load on your application servers by caching single pages inside the Web Adapter. Refer to Overview - Administration and Configuration and its subsequent documents to learn more about the page caching mechanism. Page caching is usually turned off during development to have all changes to ISML templates displayed immediately, so do not forget to turn it on in the Commerce Management application:

   1. Log in to your organization's Commerce Management application.
   2. Select the channel whose pages shall be cached.
   3. Navigate to Preferences -> Page Caching, check the box and click Apply.

2. Define Website indexing rules for Web robots.
   Avoid having your whole Intershop 7 site indexed by Web Robots instead of only your rewritten URLs. Therefore, the robots.txt has to be configured so that no robot can access URLs containing the string “/INTERSHOP/”. This leads to a site where just your rewritten URLs are indexed.

3. Online Search Engine Support
   To improve the visibility of your system, have search engine Web robots, like that of Google, index your site in a controlled manner. That means you allow selected indexing robots access to your system. To provide them with links which do not include session IDs (SID) or personalization group IDs (PGID) set the following property in $IS_SHARE/system/config/cluster/webadapter.properties: session.skipForUserAgent.0=XampleBot
   where XampleBot is the name of the robot. Thus, any user agent containing the string XampleBot will get links without IDs, allowing the robot to recheck the URL later.

4. Configure your firewall.
   It is recommended to run your Intershop 7 machines behind a firewall. The only open ports should be ports 80 and 443 of your Web Server (these are the defaults).

5. Web Adapter Statistics Monitor
   The Web Adapter Statistics monitor delivers information about your system (e.g., load, cache hit ratio, response times). The Web Server mapping of the Web Adapter Statistics monitor can be activated in $IS_HOME/httpd/conf/extra/httpd-webadapter.conf by adding the following line:

   <LocationMatch /wastatistics>
      Order  Allow,Deny
      Allow  from YourIPRange (Example: Allow from 10.10.10.0/24)
   </LocationMatch>

   After restarting the Web Server one can access the monitor page by using the URL http://<host>/INTERSHOP/wastatistics To restrict access to the monitor, follow these steps:

   1. Choose a user who should have access.
   2. Open a command line and switch to $IS_HOME/httpd/bin.
   3. Execute htpasswd -c passwordFileNameWithPath username.
   4. Choose and confirm a password.

   5. Modify the $IS_HOME/httpd/conf/extra/httpd-webadapter.conf by inserting:

      <LocationMatch /wastatistics>
        AuthType Basic
        AuthUserFile passwordFileWithPath (e.g., /path/filename)
        AuthName "username"
           require valid-user
      </LocationMatch>

   6. Modify the $IS_HOME/httpd/conf/httpd.conf by activating these modules:
      • LoadModule auth_basic_module modules/mod_auth_basic.so
      • LoadModule authn_file_module modules/mod_authn_file.so
      • LoadModule authz_host_module modules/mod_authz_host.so
      • LoadModule authz_user_module modules/mod_authz_user.so
   7. Restart the Web Server to activate the changes.
   8. Now a user with password is necessary to access the Web Adapter Statistics monitor.

Application Server

1. Java Virtual Machine
   Adjust the memory size of the Java Virtual Machines by setting the following properties in $IS_HOME\bin\tomcat.bat:

   JAVA_OPTS=%JAVA_OPTS%
   -Xms2048m 
   -Xmx2048m 
   -XX:MaxPermSize=400m 
   -XX:NewRatio=8 
   

2. Log Level

   Log levels can be defined separately for each Intershop 7 application server in the cluster or cluster wide. For development purposes, the log level is usually set to DEBUG which is not recommended for live systems, because of its negative impact on performance and the huge amount of logged data that blows up log files. Live systems should be configured to the levels ERROR, WARN, JOB and additionally to STAGING if the application server is part of a staging cluster.
   To set the log level:

   1. Log in to the SMC.
   2. Go to the Logging section.
   3. Choose a cluster-wide setting, or select a single application server and specify the log scopes (log levels).
   After changing the log level, check the content of the log files and perform a couple of requests on your site. The log level is successfully set when no debug messages can be found.

3. Clear/Backup Log Files
   You should clear or back up the log files prior to going live so that you can track potential problems more easily. To clear the log files:

   1. Stop (Intershop 7) Application and the Web Server.
   2. Move all files from $IS_SHARE\system\log to a backup directory (keep these old log files for reference).
   3. Start (Intershop 7) Application and the Web Server.

4. Jobs
   Check the jobs within the SMC for each site. Disable jobs which are not needed. Schedule jobs (if possible) for low traffic time, e.g., at night, and make sure the jobs are scheduled to run with some time offset to reduce the risk of heavy system load due to concurrent jobs.

5. ISML Source Checking
   Usually, your production system will not change often. To improve its performance disable ISML source checking during template processing by setting the following property in$IS_SHARE\system\config\cluster\appserver.properties:
intershop.template.CheckSource=false

6. ISML Precompilation
   Use ISML template precompilation to improve the performance during high traffic times. All ISML templates are precompiled during application server start so that the system does not need to compile them on user request.
   For Intershop 7 versions < 7.2.1
   To enable precompilation set the following property in $IS_SHARE\system\config\cluster\appserver.properties:
intershop.template.CompileOnStartup=true
   For Intershop 7 versions starting from 7.2.1
   The ISML templates can be precompiled by executing the Ant task
ant precompile

7. Password configuration for encryption
   Ensure that the value intershop.encryption.0.id has got a configured password which meets the requirements for a secure and safe password. For this you can check the usercredentialrules.properties, there you can find the mentioned requirements.

8. Set Correct Time
   Before going live, set the correct time and timezone for the Intershop 7 application server machines, the database machine and also the Web Server machine. They all should be in sync.

9. License Key
   Intershop 7 distinguishes between development license keys and production license keys (standard and TBR (transaction-based renting)), so please check if your license keys are made for live systems. If not, contact your Intershop account manager to request appropriate license keys.

10. Disable Development Mode of Tomcat
    By default the inner Tomcat development mode is set to 'true', which can be a performance issue. In live system installations the development mode can be set to 'false'. The suggested solution to increase the performance of production systems is edit the file web.xml in %IS_SHARE\system\config\servletEngine\conf\ as follows:

    ...
    <init-param>
      <param-name>development</param-name>
      <param-value>false</param-value>
    </init-param>
    <init-param>
      <param-name>reloading</param-name>
      <param-value>false</param-value>
    </init-param>
    ... 
    

    Note

    By setting the two values to FALSE, all properties that concern ISML template handling (these properties start with intershop.template) in appserver.properties become invalid. If, for example, you configure your system to check for newer versions of ISML templates at request (by using intershop.template.CheckSource=true) Intershop 7 will simply ignore this property. In other words, you can either disable the Tomcat development mode or be able to configure ISML source checking and ISML precompilation.
11. Disable AXIS HotDeployment
    To avoid a lot of additional file system operations you can define the below settings:

    /intershop/system/config/cluster/axis2client.xml
    <parameter name="hotdeployment">false</parameter>
    
    /intershop/system/config/cluster/axis2server.xml
    <parameter name="hotdeployment">false</parameter>
    

12. Check Correctness of all Multicast Channels
    To ensure the operational reliability of your Intershop 7 installation you have to check the Multicast settings in the following configuration files:
    • Multicast Channels from appservers, nodemanager & database
    • $IS_SHARE\system\config\cluster\appserver.properties
    • $IS_SHARE\system\config\cluster\orm.properties
    • $IS_SHARE\system\config\cluster\cache.properties
    • $IS_SHARE\system\tcm\config\tcm.properties
13. Disable Unused Sites
    Disable sites that are not used. This applies to the Intershop 7 demo sites (e.g., Inspired, PrimeTech). The demo store could even be misused to harm your systems performance by starting imports, syndication or heavy jobs. Sites can be disabled via the SLDSystem (in Operations Site) or SMC.
14. Development & Production Properties
    Intershop 7 provides the possibility to create development or production properties, with the advantage to simply switch between configurations. The environment.properties ($IS_SHARE\system\config\cluster) define which property file is taken.
    Please check if you have the correct configuration in the environment.properties.
15. Change the SMC and the TCC Passwords
    The two admin consoles can be found under the following URLs:
    • SMC: https://<host>/INTERSHOP/web/BOS/SMC
    • TCC: https://<appserver-host>:10053/tcc
    1. Log into SMC/TCC as admin.
    2. Go to Change Password.
    3. Type a new password and confirm change.
16. Configure a Mail Server
    
    1. Open the file $IS_SHARE/system/config/cluster/appserver.properties.
    2. Modify the line intershop.SMTPServer=defaultMailServer.domain.com to add your own mail server address.
17. Processor Affinity
    Configure your Application Servers to use all available processors. Intershop 7 supports processor affinity to provide better performance in case you do not bind all Application Server processes to the same CPU. Every server process (the JAVA virtual machine) can be bound to a certain CPU or can be run unbound, which means that the Intershop 7 application servers will use all cores from the machine. Please note that CPU usage of all application servers has to be covered by the license file. If the license covers all possible cores, it is recommended to run the application servers unbound. To bind the application server processes:
    1. Switch to $IS_SHARE\system\config\servers
    2. Enter the folder named with the IP address of the desired application server instance.
    3. Open the file appserver#.properties contained in this folder.
    4. Modify the line intershop.cpu.id = 0 to bind the server instance to one CPU (four CPUs have the numbers 0 to n).
18. Customer Information Center (CIC)
    Configure your system to transfer log files to the CIC where the data is processed and made accessible in a graphical way. According to your Support contract you can use the CIC. 

Intershop 7

This section is meant to provide an overview over important system settings that should be checked before going live with Intershop 7. For more information on selected topics, follow the links provided by this article, search the Support Knowledge Base, including the product documentation, or contact the Customer Support team.

Database

1. Change the Database Passwords
   Intershop 7 installs the database with a couple of default passwords. As soon as your system is about to go live, change the passwords. 

2. Backup the Database
   Make a backup of your database content before going live to preserve the original state of your database.

3. Set Oracle to Archive Mode
   Setting the Oracle server to archive mode is essential to enable the recovery of the database in the case of a system server crash, for example a disk crash.

4. Consider Oracle Tuning Measures
   Intershop has collected important Oracle tuning measures. Please refer to your DBA.

Web Server / Web Adapter

1. Page Cache
   Page caching is recommended to increase the speed of your servers. It decreases the load on your application servers by caching single pages inside the Web Adapter. Refer to the Intershop 7 user guides to learn more about the page caching mechanism. Page caching is usually turned off during development to have all changes to ISML templates displayed immediately, so don't forget to turn it on in the Commerce Management application:

   1. Log in to your Enterprise's Commerce Management application.
   2. Select the channel whose pages shall be cached.
   3. Navigate to Preferences -> Page Caching, check the box and click Apply.

2. Web Robots
   Define Website indexing rules for Web robots. Avoid having your whole Intershop site indexed by Web Robots because the URL contains session-related data. Because constantly new sessions are created - and thus new URLs - the traffic a Web Robot will generate can cause results similar to a rapid-fire assault. Moreover, the indexed pages are useless once the session timed out.

3. Online Search Engine Support
   To improve the visibility of your system, have search engine Web robots, like that of Google, index your site in a controlled manner. That means you allow selected indexing robots access to your system. To provide them with links that do not include session IDs (SID) or personalization group IDs (PGID) set the following property in $IS_HOME/share/system/config/cluster/webadapter.properties:
   session.skipForUserAgent.0=XampleBot
   where XampleBot is the name of the robot. Thus, any user agent containing the string XampleBot will get links without IDs, allowing the robot to recheck the URL later.

4. Configure your Firewall
   It is recommended to run your Intershop machines behind a firewall. The only open ports should be ports 80 and 443 of your Web Server (these are the defaults). 

5. Web Adapter Statistics Monitor
   The Web Adapter Statistics monitor delivers information about your system (e.g., load, cache hit ratio, response times). The Web Server mapping of the Web Adapter Statistics monitor can be activated in $IS_HOME/httpd/conf/httpd.conf by adding the following line:

   AddHandler iswebadapter .wastatistics
   

   After restarting the Web Server one can access the monitor page by using the URL http://<host>/is-bin/INTERSHOP.wastatistics . To restrict access to the monitor, follow these steps:

   1. Choose a user who should have access.
   2. Open a command line and switch to $IS_HOME/httpd/bin
   3. Execute htpsswd -c passwordFileNameWithPath username
   4. Choose and confirm a password.
   5. Modify the $IS_HOME/httpd/conf/httpd.conf by inserting:

      <LocationMatch (w|W)(A|a)(S|s)(T|t)(A|a)(T|t)(I|i)(S|s)(T|t)(I|i)(C|c)(S|s)>
        AuthType Basic
        AuthUserFile passwordFileWithPath
        AuthName "username"
        require valid-user
      </LocationMatch>
      

   6. Restart the Web Server to activate the changes.
   7. Now a user and password is necessary to access the Web Adapter Statistics monitor. Check the httpd.conf file. The configuration file contains an alternative directive that allows for access filtering by IP ranges.

Application Server

1. Java Virtual Machine
   Adjust the memory size of the Java Virtual Machines by setting the following properties in $IS_HOME/bin/tomcat.bat:

   JAVA_OPTS=%JAVA_OPTS%
   -Xms256m 
   -Xmx512m 
   -XX:MaxPermSize=192m 
   -XX:NewRatio=8
   

2. Log Level
   Log levels are defined separately for each application server in the cluster. For development purposes, the log level is usually set to DEBUG which is not recommended for live systems, because of its negative impact on performance and the huge amount of logged data that blows up log files. Live systems should be configured to the levels ERROR, FATAL, SYSEVENT, WARN, and JOB, and additionally to STAGING if the application server is part of a staging cluster. Also make sure, SQL logging is disabled.
   To set the log level:

   1. Log in to the System Management application.
   2. Go to the Logging section.
   3. Choose a cluster-wide setting, or select a single application server and specify the log scopes (log levels).

   After changing the log level, check the content of the log files and perform a couple of requests on your site. The log level is successfully set when no debug messages can be found. 

3. Clear Log Files
   You should clear the log files prior to going live so that you can track potential problems more easily. To clear the log files:

   1. Stop all Intershop applications and the Web Server.
   2. Move all files from $IS_HOME/share/system/log to a backup directory (keep these old log files for reference).
   3. Start the application server and the Web Server.

4. Jobs
   Check the jobs within the System Management application for each site.

   1. Disable jobs which are not needed.

   2. Schedule jobs (if possible) for low traffic time, e.g., at night, and make sure the jobs are scheduled to run with some time offset to reduce the risk of heavy system load due to concurrent jobs.

5. ISML Source Checking
   Usually, your production system will not change often. To improve its performance disable ISML source checking during template processing by setting the following property in$IS_HOME/share/system/config/cluster/appserver.properties:
   intershop.template.CheckSource=false

6. ISML Precompilation
   Use ISML template precompilation to improve the performance during high traffic times. All ISML templates are precompiled during application server start so that the system does not need to compile them on user request. To enable precompilation set the following property in $IS_HOME/share/system/config/cluster/appserver.properties:
   intershop.template.CompileOnStartup=true
   Alternatively, the ISML templates can be precompiled by executing the Ant task ant precompile.

7. Set Correct Time
   Before going live, set the correct time and timezone for the application server machines, the database machine and also the Web Server machine. They all should be in sync.

8. License Key
   Intershop distinguishes between development license keys and production license keys, so check if your license keys are made for live systems. If not, contact your Intershop account manager to request appropriate license keys.

9. Disable Development Mode of Tomcat
   By default the inner Tomcat development mode is set to true, which can be a performance issue. In live system installations the development mode can be set to false. The suggested solution to increase the performance of production systems is edit the file web.xml in %IS_SHARE\system\config\servletEngine\conf\ as follows:

   ...
   <init-param>
     <param-name>development</param-name>
     <param-value>false</param-value>
   </init-param>
   <init-param>
     <param-name>reloading</param-name>
     <param-value>false</param-value>
   </init-param>
   ...

   Note

   By setting the two values to FALSE, all properties that concern ISML template handling (these properties start with intershop.template.) in appserver.properties become invalid. If, for example, you configure your system to check for newer versions of ISML templates during startup (by using intershop.template.CheckSource=false) Intershop will simply ignore this property. In other words, you can either disable the Tomcat development mode or be able to configure ISML source checking and ISML precompilation.

   
   

10. Check correctness of Cache Synchronization Settings
    To ensure all application servers can participate in the cache synchronization communication, check the Multicast settings in the following configuration files:

    • $IS_HOME\share\system\config\cluster\appserver.properties

    • $IS_HOME\share\system\config\cluster\orm.properties

    • $IS_HOME\share\system\tcm\config\tcm.properties

11. Disable Unused Sites
    Disable sites that are not used. This applies to the Intershop demo sites (e.g., inSPIRED). The demo store could even be misused to harm your systems performance by starting imports, syndication or heavy jobs. Sites can be disabled in SLDSystem or PrcSystem or the System Management application.

12. Change the System Management application and the Tomcat Cluster Management Console passwords
    The two admin consoles can be found under the following URLs:
    SM: https://<host>/is-bin/INTERSHOP.enfinity/BOS/SMC
    TCC: https://<appserver-host>:10053/tcc

    1. Log into System Management application as admin.
    2. Go to Change Password.
    3. Type a new password and confirm change.

13. Change the Operations and PrcOperations Passwords
    The two Commerce Management applications can be found under the following URLs:
    Operations: https://<host>/is-bin/INTERSHOP.enfinity/WFS/SLDSystem
    PrcOperations: https://<host>/is-bin/INTERSHOP.enfinity/WFS/PrcSystem

    1. Log into Operations as admin.
    2. Go to 'Profile'
    3. Type a new password and confirm change.

14. Configure a Mail Server

    1. Open the file $IS_SHARE/system/config/cluster/appserver.properties.
    2. Modify the line intershop.SMTPServer=defaultMailServer.domain.com to add your own Mail server address.

15. Processor Affinity
    Configure your application servers to use all available processors. Intershop supports processor affinity to provide better performance. Every server process (the virtual machine) is bound to a certain CPU by the operating system. Please note that every application server instance requires its own license. To bind the application server processes:

    1. Switch to $IS_HOME/share/system/config/servers.
    2. Enter the folder named with the IP address of the desired application server instance.
    3. Open the file appserverX.properties contained in this folder.
    4. Modify the line intershop.cpu.id = 0 to bind the server instance to one CPU (four CPUs have the numbers 0 to 3).

16. Intershop Commerce Insight (ICI)
    Configure your system to transfer log files to the ICI where the data is processed and made accessible in a graphical way. Everyone with a valid Support contract can use the ICI. For more detailed information refer to Overview - Intershop Commerce Insight (ICI) and its subsequent pages.

17. Optimize Garbage Collection
    Set intershop.runFinalizationAfterEachRequest = false in $IS_SHARE/system/config/cluster/appserver.properties, so the Java Virtual Machine decides when a garbage collection is triggered.

For more details refer to Overview - Administration and Configuration as well as the Checklist for Going Live:

• Overview - Administration and Configuration and its subsequent documents
• Intershop 7 Checklist for Going Live

Avoid Sensitive Data Exposure

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>
• <eserver>/share/system/config/cluster/appserver.properties
  • intershop.encryption.passphrase=<encryption and decryption pass phrase>
• <eserver>/share/system/config/cluster.id
  • unique identifier of the ICM Suite cluster; automatically generated at server startup if the file does not exist; used to sign session identifiers
• <eserver>/httpd/conf/ssl/
  • Private key file for SSL server certificates
• <eserver>/share/system/config/cluster/ssh
  • SSH keys and pass-phrases for communication with the reporting server (created by "ant ssh_keygen")
• <eserver>/engine/jdk/jre/lib/security/
  • Java security configuration
• <eserver>/share/system/tcm/config/
  • SSL configuration for the Tomcat Cluster Management

Keep the number of people with access to the file system as small as possible.

System Management Application

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 System Management application. 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 System Management application. Depending on Intershop version this property is located in the configuration file of different cartridges:

• <eserver>/share/system/config/cartridges/monitor.properties
• <eserver>/share/system/config/cartridges/core.properties
• <eserver>/share/system/config/cartridges/bc_organization.properties

Data Transmission

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 are not using HTTPS across the board.

HTML Form Transmission

Another very important thing is the transmission of HTML forms and their 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 behavior 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 does not log HTTP content from the request body there is no need to worry about sensitive data to be logged into log files.

Data Encryption

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.

Encryption:

• EncryptionUtils#encrypt(byte[],String) and 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: algorithm:[cipher_text].
• EncryptionUtils#encrypt(byte[],String,String) and 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].

security.provider.n = masterClassName

Decryption:

• EncryptionUtils#decrypt(byte[],String) and 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(byte[],String,String) and EncryptionUtils#decrypt(char[],String,String) decrypt the given cipher text with the given password phrase using the specified encryption algorithm.

Furthermore, the EncryptionUtils#encrypt(byte[],String) and encrypt(char[],String) as well as EncryptionUtils#decrypt(byte[],String) and 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.

Function Level Access Control

Missing Function Level Access Control

Pipeline Access

Requests to an Intershop system are usually handled by the following components in the following order:

1. Web Server
2. Web Adapter
3. Application Server Servlet
4. Application Server Pipeline

Not all component must be involved with every request, e.g., the Web Adapter responds with a cached paged, making the Application Server Servlet and pipeline execution obsolete.
But as a last consequence functionality of the web application is mapped/implemented by pipelines, thus the access to those must be controlled.

Call Mode "private"

Each start node of an Intershop Commerce Management pipeline has a call mode setting that can be changed using Intershop Studio. This call mode setting can be private or public:

• private – If the call mode is set to private, the pipeline cannot be executed directly over HTTP. It is only callable from another pipeline by using a call node or a jump node. Alternatively, the pipeline can be executed by an Intershop job.
• public – The pipeline execution is not limited. Besides the ways described above, it can also be called over HTTP. If a pipeline has multiple start nodes, the call mode has to be set for each start node individually.

By setting the call mode it is not possible to configure specific access control for different users.

Centralized Pipeline Access Control

The CorePrefix pipeline is a prefix pipeline which is provided as a default. The pipeline checks if a user has the required permission to run a called pipeline. This is, basically, a two-step process:

• First, the CorePrefix pipeline determines the permissions that are required to execute the called pipeline at the specified Start Node in the given site context.
• Then, it checks whether the current user's permissions match the previously determined permissions. If so, the called pipeline will be executed; if not, the execution is denied and an error page will be displayed.

For each pipeline, access control lists define the permissions a user needs to execute this pipeline in general, or a specific start node of this pipeline. Every cartridge or site that has pipelines provides a pipelines-acl.properties file, located in

• $IS_HOME/share/system/cartridges/<cartridge_name>/release/pipelines for cartridge pipelines, or
• $IS_HOME/share/system/sites/<site_name>/<active_dir>/pipelines for pipelines directly bound to a specific site.

The pipelines-acl.properties file(s) includes the access control list (ACL) for every pipeline of the cartridge or site whose access should be restricted.
These access control lists are loaded into the pipeline cache upon server startup or pipeline reload.

General Pipeline Security

Since pipeline execution can be triggered from external sources via an URL, special care is necessary to secure pipelines, making sure that a pipeline responds only to requests from authorized clients.

Public, Private and Include Start Nodes

The configuration parameters for a start node include the call mode parameter. The call mode determines whether a pipeline can be triggered from an external source using HTTP requests, or from an internal source only using call or jump nodes. The call mode parameter for start nodes can have the following values:

• Public for access from an external source such as the storefront, using (for example) HTTP requests.

  Example for a public call:

  <a href=“#URL(Action(‚ViewHomePage-Start‘))#“>…</ a >

  Such a public request allows only to call a public start node.

• Include for access via remote include calls (Web Adapter includes, <WAINCLUDE>).

  Example for a include call:

  <isinclude url=“#URL(Action(‚PipelineXyz-Start‘)#”>

  An included request allows to call a public or an include start node.

• Private for access from an internal source such as another pipeline, using call or jump nodes.

  Example for a internal call:

  < ispipeline pipeline=”ProcessPagelet-TemplateCallback” params=”#ParamMap#”>

  An internal request allows to call a public, an include or a private start node.

For example, many viewing pipelines are triggered by external sources via HTTP requests, hence need to have a public start node. On the other hand, processing pipelines are typically called from viewing pipelines. Therefore, processing pipelines typically have private start nodes.

Prefix Pipelines

Prefix pipelines are generic pipelines which perform certain checks before the pipeline that has actually been requested is executed. Prefix pipelines therefore provide a powerful mechanism to prevent unauthorized access to public pipelines.

Intershop 7 supports so-called site prefix pipelines. The site preference value SitePrefixPipeline specifies the name of a pipeline which is automatically called before any public pipeline in the site is executed. The default value is set to the CorePrefix pipeline. See the figure below for details on this pipeline.

The pipelet processor checks the SitePrefixPipeline preference value only once, the first time a pipeline in the site is executed. The SitePrefixPipeline preference value is re-read only if the pipelines of the site or all pipelines in the system are reloaded.

If a pipeline is executed and the site's SitePrefixPipeline preference value contains a prefix pipeline name, the prefix pipeline is looked up in the normal manner and is then executed. This also means that a prefix pipeline can be overloaded in the usual way. 
Different versions of the prefix pipeline can be defined using the start nodes:

• process
• view, or
• backoffice

These different versions are executed depending on the type of the pipeline (Process, View, or Backoffice) triggering the prefix pipeline.

For example, if the original pipeline being executed is of type process, a start node process is searched for in the prefix pipeline. If the system cannot find one, the pipelet processor looks for a default start node named Start. The name of the originally called pipeline and the start node name are put into the prefix pipeline dictionary using the CurrentPipelineName and CurrentStartNodeName keys.

The originally called pipeline is not executed after the site prefix pipeline if the following happens:

• The site prefix pipeline ends with an interaction.
• The site prefix pipeline ends with an exception, in which case the error handler of the site prefix pipeline is looked up and executed.

If the site prefix pipeline ends with a named end node, the originally called public pipeline is executed. The SitePrefixEndNodeName value of the site prefix pipeline is passed to the dictionary. The values of the site prefix pipeline dictionary are available to the original pipeline as well.

CorePrefix Pipeline

The CorePrefix pipeline is a prefix pipeline which is provided as a default. The pipeline checks if a user has the required permission to run a called pipeline. This is, basically, a two-step process:

• First, the CorePrefix pipeline determines the permissions that are required to execute the called pipeline at the specified start node in the given site context.
• Then, it checks whether the current user's permissions match the previously determined permissions. If so, the called pipeline will be executed; if not, the execution is denied and an error page will be displayed.

The permissions themselves are configured in the pipelines-acl.properties file, located in the pipeline directory of every cartridge, and pre-loaded during the pipeline cache initialization.

Pipeline Access Control Lists

If a pipeline requires a permission of the requester to execute the pipeline in general, or a specific start node of this pipeline, the pipeline's cartridge contains a pipelines-acl.properties file. The pipelines-acl.properties file includes the access control list (ACL) for every pipeline of the cartridge or site whose access should be restricted. These access control lists are loaded into the pipeline cache upon server startup or pipeline reload. 
The pipelines-acl.properties located in

• <IS_HOME>\share\system\cartridges\<cartridge_name>\release\pipelines 
  for cartridge pipelines, or
• <IS_HOME>\share\system\sites\<site_name>\1\pipelines 
  for pipelines directly bound to a specific site.

ACL Lookup Process

As pipelines are always executed within a site context, the common pipeline lookup and overload mechanism must apply to the ACL lookup as well. The following steps are performed:

1. All available sites in the system are determined
2. The site specific ACLs are read from the pipeline-acl.properties located in the site's pipeline directory and stored into the site pipeline cache

3. The cartridges that are currently loaded in the given site are determined

   Note

   The order within the list of cartridges bound to a site is relevant. The system sequentially searches for cartridge resources in a top-down manner, starting with the first cartridge in the list.

4. For each cartridge in the list, the pipeline ACLs are loaded sequentially.
   Since a cartridge can be loaded in several sites, the cache prevents from loading the ACLs of the same cartridge again and again.
5. Each loaded entry of the cartridge's ACL file is checked against the site pipeline cache.
   Only those entries that have not already been added to the cache are added. Thus, ACLs can be overloaded like pipelines by adding the access control list to a cartridge which is on top of the lookup list or to the ACL list of the site.

The access control list lookup also considers cartridges and sites that do not define any pipelines. In this case, the cartridge's or site's pipeline directory only contains the file pipelines-acl.properties. This allows developers to overload the ACLs of pipelines by their project specific cartridges or sites.

ACL Syntax

The pipelines-acl.properties files must match a specific syntax. As all properties files, they are made of key-value pairs. The pipelines-acl.properties files define the required permission for each pipeline-start node combination. 
The following lines illustrate the ACL syntax:

<-- permission list for a given context for a specific start node of a pipeline -->
< PipelineName >-< StartNodeName >=< Context >:< PermissionID >
<-- permission list for a given context for an entire pipeline -->
< PipelineName >=< Context >:< PermissionID >

The key is PipelineName-StartNodeName. The value is a semicolon separated list of Context:PermissionID pairs. In addition, you can define a default access control list for each pipeline without a start node, or an empty access control list for a pipeline.

...
ViewCatalog=Channel:NONE;Organization:SLD_MANAGE_CATALOGS
ViewCatalog-Dispatch=Channel:NONE;Organization:NONE
ViewCatalog-Edit=Channel:NONE;Organization:SLD_VIEW_CATALOGS
...
ViewCatalogCategoryEditing=Enterprise:SLD_MANAGE_CATALOGS

The entries for ViewCatalog-Edit, ViewCatalog-Dispatch and ViewCatalog are treated as independent entries and are not merged during the cache initialization. 

A call for ViewCatalog-Edit returns Channel:NONE;Organization:SLD_VIEW_CATALOGS (the context Channel denotes inSPIRED-inTRONICS and the context Organization denotes inSPIRED), a call for ViewCatalog-Dispatch returns an empty list. 
A call for ViewCatalog returns Channel:NONE;Organization:SLD_MANAGE_CATALOGS which is the pipelines fallback if a specific start node of the pipeline is not listed in the pipelines-acl.properties file. 
The context Enterprise of the pipeline ViewCatalogCategoryEditing means both, the Organization context and the Channel context.

For example, the ACL:

ViewCatalog-Edit=Channel:NONE;Organization:SLD_VIEW_CATALOGS

 means that if a user wants to start the pipeline ViewCatalog via the start node Edit, the permission SLD_VIEW_CATALOGS must be checked against the authorization object Organization. The number of Context:PermissionID pairs per access control list is not limited, but a Context:PermissionID pair should not appear more than one time in an access control list.

See the Intershop Studio User Guide - Creating Pipelines | Manage pipeline Access Control for detailed information on how to manage the permissions of the access control list. The Intershop Studio User Guide is available as Online Help of Intershop Studio.

Secure Jumps On Form Submits

In Intershop it is common that a web form submit can trigger different actions. The actual action is not determined by the action attribute of the web form, but by the value of the submit button. Here is an example from the BrowseCatalogCatagory.isml template:

[...]
 
<form action="#URL(Action('ViewCategory-Dispatch'))#" method="post" name="editCategoryForm">
	<table border="0" cellspacing="4" cellpadding="0">
		<tr>
			<td class="button">
				<input type="hidden" name="CatalogID" value="<isprint value="#Catalog:Id#">"/>
				<input type="hidden" name="CatalogUUID" value="<isprint value="#Catalog:UUID#">"/>
				<input type="hidden" name="ParentCategoryID" value="<isprint value="#Category:Parent:UUID#">"/>
				<input type="hidden" name="CatalogCategoryID" value="<isprint value="#Category:UUID#">"/>
				<input type="submit" name="edit" value="<isif condition="#isDefined(CurrentUserPermissionMap:SLD_MANAGE_CATALOGS) AND (NOT(Catalog:isProxy))#">Edit Properties<iselse>View Properties</isif>" class="button"/>
			</td>	
		</tr>
	</table>
</form>


[...]

To avoid bypassing the ACL pipeline access checks it is strongly encouraged to use the SecureJump-Start pipeline when dispatching the action as this one does a explicit permission check on the resolved action. The simple example below shows how form actions should be dispatched at pipeline level.

Restrict Access to Applications

Access to applications like Commerce Management, Server Management Console (SMC) and Cluster Management (Tomcat Cluster Console (TCC)) should be restricted to internal IPs only.

To do so, replace the snippets from the web server configuration in server/local/httpd/conf/extra/httpd-deflate.conf from this:

#
# Deflate output filter configuration
#
<LocationMatch ^/INTERSHOP/(web|static)/>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/js
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/xml application/xhtml+xml
    AddOutputFilterByType DEFLATE application/javascript application/x-javascript
    
    # these lines are for some older browsers that do not support compression
    # of files other than HTML documents
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</LocationMatch>

to this:

#
# Deflate output filter configuration
# Restrict Backoffice, SMC and TCC to internal IPs
#	Backoffice: /INTERSHOP/web/WFS/SLDSystem
#	Server Management Console: /INTERSHOP/web/BOS/SMC
#	Cluster Management: /tcc
#
<LocationMatch (^/INTERSHOP/(web|wastat|[^/]+)/(WFS|BOS)/(SLDSystem|SMC|[^/-]*-Site)|^/tcc)>
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/js
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/xml application/xhtml+xml
    AddOutputFilterByType DEFLATE application/javascript application/x-javascript
    
    # these lines are for some older browsers that do not support compression
    # of files other than HTML documents
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

	Order Allow,Deny
	Allow from 192.168.0.0/16
</LocationMatch>

If it is necessary to access from outside the office intranet the right choice would be to use an VPN client to connect to the companies internal network.

Prevent Cross-Site Request Forgery (CSRF)

In order to counter a CSRF attack, the strategy proven most effective is the synchronizer token pattern. In the absence of an attack it works as follows:

1. Presented with a request from an authorized user, the web application generates a cryptographically strong pseudo-random number and stores it at the user's session.
   This number is called the synchronizer token.

2. The synchronizer token is embedded into every part of a response page that can trigger actions with side effects.

   The synchronizer token is neither sent nor stored as a browser cookie.

3. The authorized user triggers one of these requests from the page.
4. The web application receives the request and validates that the synchronizer token embedded in the request matches one stored at the user's session and performs the requested action.

An attacker trying to run a CSRF attack on this web application will now fail because he cannot retrieve or guess the synchronizer token and the web application will thus reject to perform any forged requests.

The cross-site request forgery guard (CSRFGuard for short) is an implementation of the synchronizer token pattern, especially tailored for Intershop applications. It is not the equally named CSRFGuard by OWASP.

For additional information about the CSRFGuard please refer to Overview - Security & Data Protection and its subsequent documents.

Circumvent Components with Known Vulnerabilities

Intershop updates components and libraries with every major and some minor releases to close potential security leaks with the updated components and libraries.
The Intershop Support department informs about important security updates via newsletter security bulletin that is regularly sent to the named resources on the Intershop support contract.

Avoid Unvalidated Redirects and Forwards

Intershop internally implements redirects as countermeasure for login via back button vulnerability.

The Redirect pipeline's start node Start has the call mode set as private, and thus cannot be called directly with an HTTP request.

Firewall Configuration

It is recommended to run your Intershop 7 machines behind a firewall and/or reverse proxy. The only open port should be port 443 of your Web Server (this is the default). Port 80 should not be necessary anymore as this HTTP traffic is not encrypted. On top of this Google ranks sites using HTTP traffic lower in their search results.

Log File Handling

Define a clear strategy for log files, backups and archives. Those processes need to be documented and most importantly be executed by the book. From a GDPR point of view, deletion of those files (after retention period) is the most important thing besides security measures to keep them secure.

Jobs

Check the jobs within the SMC for each site. Disable jobs that are not required. Schedule jobs (if possible) for low traffic time, e.g., at night, and make sure the jobs are scheduled to run with some time offset to reduce the risk of heavy system load due to concurrent jobs.

Delete Jobs for personal data like Basket, Session need to run in order to delete them on a regular basis.

Password Configuration for Encryption

Ensure that the value intershop.encryption.0.id has got a configured password which meets the requirements for a secure and safe password. For this you can check the usercredentialrules.properties, there you can find the mentioned requirements.

Regarding the PA-DSS requirements, you have to ensure, that intershop.encryption.keystore.password is configured (90 characters) in your encryption.properties.

Disable Unused Sites

Disable sites that are not used. This applies to the Intershop 7 demo sites (e.g., PrimeTech). The demo store could even be misused to harm your systems performance by starting imports, syndication or heavy jobs. Sites can be disabled via the SLDSystem (in Operations Site) or SMC.

Disable Inactive Users

When employees are leaving the company or accounts are not used anymore, those accounts need to be disabled. In case of employees leaving the company you should consider deleting any personal data from this employee unless there is a legitimate interest, e.g., legal requirements. 

Development & Production Properties

Intershop 7 provides the possibility to create development or production properties, with the advantage to simply switch between configurations. The file environment.properties ($IS_SHARE\system\config\cluster) defines which property file is taken.
Please check if the configuration in environment.properties is correct.