Running a webserver security is important. Here we discuss serveral aspects of securing your OpenCms server installation.
1 Restrict access to the OpenCms workplace via an IP range
Sometimes it is necessary to make the OpenCms workplace only available for specific IPs. This can be achieved by setting up a firewall application for the web server that filters the access to the OpenCms workplace.
Another option is to add additional rewrite rules to the virtual host configuration of the OpenCms workplace in your Apache configuration.
The following example blocks all IP addresses that do not start with 127.0.. It can be modified to allow other IPs to access the OpenCms workplace server. For more details, refer to the Apache mod_rewrite module documentation.
<VirtualHost ...>
# Restrict access to workplace server to specific IP addresses
RewriteCond %{REMOTE_ADDR} !^127\.0\..*
RewriteRule .* - [F]
</VirtualHost>2 Using strong passwords
The OpenCms workplace users should be advised to use "strong" passwords to log in to the OpenCms workplace, at least with a minimum character count. OpenCms just checks if a password has a minimum length of 4 characters. See the following subsection for an alternative password validation method.
The "Admin" user password should be changed immediately after OpenCms was installed successfully.
2.1 User defined password validation handler
It is possible to write a user defined password validation handler class to force the OpenCms users to enter a "strong" password matching the requested policies. Therefore, the interface org.opencms.security. I_CmsPasswordHandler has to be implemented. Usually, it is sufficient to extend the class CmsDefaultPasswordHandler in the same package and overwrite the method validatePassword(String password).
This handler class has to be configured in the OpenCms configuration file WEB-INF/config/opencms-system.xml. The class attribute value of the element <passwordhandler> has to be set to the new password validation handler class.
<passwordhandler class="com.example.CmsCustomPasswordHandler">
<encoding>UTF-8</encoding>
<digest-type>MD5</digest-type>
<param name="compatibility.convert.digestencoding">false</param>
</passwordhandler>3 Avoiding cross site scripting (XSS) attacks
The OpenCms workplace and its dialogs are programmed in a way that XSS attacks should not be possible.
This is not the case for HTML pages generated for the website using a template. The template programmer has to care for protection of the pages by using standard Java mechanisms (e.g. to use JSTL tags).
For example, no request parameter values should be printed out directly using the EL (element language). They should be escaped using the JSTL (Java Standard TagLib). Of course the JSTL core tag library has to be defined in the head of the JSP: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>.
This is how to display the request parameter value "query" in a JSP:
- Wrong:
${param.query} - Correct:
<c:out value="${param.query}" />or equally<c:out value="${param.query}" escapeXml="true" />the<c:out>tag escapes XML characters by default)
4 Replicate databases
Using the database replication feature of the (non-free) Alkacon OpenCms Enterprise Extensions, it is easy to replicate the complete (or parts of the) OpenCms repository data to remote database instances.
These remote instances are also automatically updated when changed data is published. Using this feature it is for example possible to have a separate OpenCms "work" instance inside of a secured Intranet, and a public "production" OpenCms server in a DMZ.
The OpenCms workplace is not available at all on the public "production" server.
5 SQL injection
OpenCms only uses prepared statements when accessing the database through JDBC, so it is not possible to pass database queries directly through OpenCms.
So far there are no known leaks in OpenCms enabling SQL-Injection.
Customized website applications should use the OpenCms API and prepared statements to access the database for security reasons.