Security Best Practices - Documentation topics on: best practices,security,security policy,.

Security Best Practices

dotCMS is committed to providing the highest level of security for our products and customer sites. We demonstrate that commitment by internally reviewing and scanning all our code for vulnerabilities, keeping up with the latest security concerns and tools, and addressing security issues and potential vulnerabilities proactively.

This document lists a number of security best practices. We recommend that you read this entire document before publishing your own sites with dotCMS, and we strongly recommend that you implement these best practices for any production server, especially any public-facing server.

Note: The following security practices are implemented by dotCMS for all dotCMS cloud clients. For more information on dotCMS Enterprise Cloud, please contact dotCMS Sales.

Recommended Approaches

Although specific configurations and practices are necessary to implement strong security, it is often just as important to adopt an overall approach to security that ensures that, when resources are scarce or there are conflicting needs, appropriate choices can be made about which specific security practices to implement. The following are some approaches we recommend to help you identify, implement, and manage your security practices for your dotCMS site.

Continual Improvement

Maintaining security of web sites can be a very complex and rapidly evolving challenge for organizations of any size, and even this relatively long list of best practices is not comprehensive. It may be difficult to implement all of these best practices for all sites, or to implement all of these practices for new sites.

However since security is always changing, it is best to take an approach of continual improvement. Therefore, even if it is not possible or practical for you to implement all of these best practices immediately, we recommend that you implement as many as you can now, and then progressively implement additional practices as you are able to.

Layered Security

Individual security measures may be defeated by determined attackers, and vulnerabilities may be discovered at any time in even long-standing security protocols. Therefore it is best to implement multiple layers of security for every potential access point, to ensure that one or more layers of security remain even if one layer is compromised or defeated.

In simple terms, this just means that you should, when possible, implement as many of these best practices as you can. Most of these practices overlap with each other, so you will automatically achieve multiple layers of security in some areas when multiple best practices are implemented and maintained. As you continue to improve, or in order to address specific security concerns, you may review your practices to ensure you have multiple layers of security covering specific areas of concern.

White List Access

It is very difficult to anticipate all possible attacks and vulnerabilities that may be attempted or exploited in the future. This makes it extremely difficult to implement security using a “black list” apporach, attempting to filter or limit malicious behavior.

It is instead both easier and more secure to implement a “white list” approach, where you only allow a small set of acceptable behavior, and reject all access or behavior which does not meet your requirements. Therefore, whenever possible, it is best to use a “white list” approach, and explicitly define and enforce what is allowed. It is much easier to expand the list of allowed actions later (when a user is unable to perform their required tasks) than it is to detect and close a vulnerability after it has been exploited.

Server Configuration

The applications you run on your server, including dotCMS, can only be as secure as your server itself. If your server security is compromised, efforts to secure dotCMS can not protect your server and site from being compromised. Therefore it is vital that you ensure you configure your server for maximum security.

The following are several steps you can use to increase the security of your server:

Run dotCMS on a Dedicated Server

We strongly recommend that dotCMS be run on its own dedicated server. In addition to improving the performance and reliability of the server, this also eliminates the need for additional services and applications and additional open ports which could provide access points to attack the security of your server.

Disable all Unused Ports

Malware often targets services that run on dynamically-allocated (autowire) ports. Therefore it is important that you use a firewall to prevent access to these ports to protect against potential zero-day (unpatched) vulnerabilities.

Block access to all ports except Connectors for your application server, from all sources outside of the dotCMS cluster. This includes blocking access to these ports from all non-dotCMS sources on the same subnet of your internal or DMZ subnet.

Disable or Uninstall All Unused Services and Applications

You should run only the minimum services, and install only the minimum applications (and plugins) required for proper operation of your operating system, database, and application server. Uninstall and/or disable all unused applications and services (including non-essential operating system services), and limit the number of additional applications and plugins installed to the minimum necessary to run your dotCMS server and applications.

Limit Access Points with a Firewall

You should close off as many ports as possible on your server, to limit the number of potential access points which could be exploited by an attacker. Install a firewall or enable your operating system's built-in firewall, and make sure the firewall is configured to close off as many access points as possible.

Use and Maintain Anti-Virus Software

If possible, use anti-virus software to:

  • Monitor inbound and outbound traffic for malicious payloads.
  • Scan files uploaded to the server.
  • Scan for malicious software behavior on the server.

Restrict Server Permissions

The dotCMS server accesses files within your dotCMS installation folder on your server. However, depending on your configuration, content and permissions, it may be possible (and desireable) for dotCMS to attempt to access other folders outside the dotCMS installation folder.

To ensure that sensitive system files can not possibly be accessed unintentionally, it is recommended that the user account which runs dotCMS be set to a non-root account (non-Administrator on Windows), and that the user account which runs dotCMS only be given access to the specific directories you wish for dotCMS to be able to access.

In addition, the files in the dotCMS directory are critical to the operation of dotCMS, and should not be accessible except to authorized users. Ensure that the owner and permissions of the dotCMS installation folder are set propertly to prevent unauthorized access.

Implement Strong Database Security

Many of the best practices which apply to configuring your server also apply to installing and configuring your database. Although the specific steps to take vary based on your database and how you intend to use it, consider the following guidelines:

  • If there is a default database administrator account, disable it and create a new administrator account with a new unique name.
  • Use strong passwords for all database users.
  • If there are any database services, applications, or plugins which are not used or needed (such as replication), disable or uninstall them.
  • Close off open ports for database services or features which are not used.
  • Install the database in a folder which can not be accessed by inappropriate users.
  • Limit the permissions of the user account used to install the database to the minimum necessary.

Control Database Permissions

It is also important to properly control access within the database itself:

  • Use the inherent security of your database to ensure that only authenticated users can access the database.
    • Disable all default or built-in database users.
      • Create new database user accounts with non-standard names for all your database users.
    • Use secure passwords for all database users.
  • Do not include any strings in SQL queries that originate with user input.
  • Limit all database users to the minimum access required.
    • If any of your code or pages requires access to run queries against any database (including, but not limited to, the dotCMS database), create a database user account with very limited permissions, and run the queries with this limited user account.

In addition, if you access the database from within any of your application code or plugins, make sure to follow secure database coding practices, especially Sanitizing all SQL Queries.

Maintain the Latest Software Versions and Patches

Operating System and software vendors regularly release updates which include security enhancements and fixes for potential security issues. Therefore it is crucial that you keep all your software up to date to ensure you have protection from known security vulnerabilities. This includes, but is not limited to, all of the following:

In addition, if you are using Anti-Virus software, ensure that both the software version and the signature files are updated as frequently as possible.

The following links lead to sites which provide security information and/or security patches for many of the different platforms dotCMS works with.

Always Upgrade to the Latest dotCMS Release

Each new releases of dotCMS may include fixes for security vulnerabilities discovered in the dotCMS code base. This may include vulnerabilities listed on the Known Security Issues page, vulnerabilities or potential vulnerabilities discovered and fixed internally, changes to mitigate or prevent known security vulnerabilities in operating systems or other software, and security enhancements meant to prevent potential exploits even if no actual vulnerability has been found or demonstrated.

Therefore, for maximum security it is important that you always upgrade to the most recent dotCMS release as soon as possible. If for any reason you are not able to upgrade to the latest dotCMS release, please contact dotCMS Support and ask if there are any security hotfixes available for the version of dotCMS you are using.

Note: dotCMS automatically and proactively upgrades all dotCMS Cloud customers to the latest dotCMS version immediately after each new release.

Keep Up-to-Date with Third Party Security Fixes

Ensure that you maintain the latest security fixes for all third-party software run on your dotCMS server, including elements of the server platform such as the operating system and database, and any third party packages you've integrated into dotCMS through static or dynamic plugins, SQL queries, or other integration methods.

To assist you in finding and maintaining current security levels on your dotCMS server platform, the following is a partial list of sites which provide up-to-date security information for major operating systems, databases, application servers, and Java versions supported by dotCMS.

Operating System Security Sites

The following sites provide security information and updates for the most common operating systems used with dotCMS:

Operating SystemSecurity Site
Red Hat LinuxRed Hat Product Security Center
Red Hat Security Advisories, Bug Fixes, and Enhancements for Active Products
OS XOS X Security Configuration Guides
Apple Security Updates
WindowsMicrosoft TechNet Security Center

Database Security Sites

The following sites provide software updates and security information for databases supported for dotCMS production sites:

DatabaseSecurity Site
MS SQL ServerSQL Server Security page
Microsoft TechNet Security Center
MySQLMySQl Security Documentation
OracleOracle Critical Patch Updates, Security Alerts and Third Party Bulletins
PostgresPostgreSQL Security Information

Note: The H2 database is not included here because it is NOT intended for production use. Neither the performance nor security characteristics of the H2 database are appropriate for production systems.

Application Server Security Sites

The following sites provide security information and updates for the application servers supported by dotCMS:

Application ServerSecurity Site
TomcatApache Tomcat Security Updates
JBossJBoss EAP 6.1 Security Guide
WebLogicOracle Critical Patch Updates, Security Alerts and Third Party Bulletins
WebSphereWebSphere Application Server Security page

Java Security Sites

The following sites provide security information for the Java Virtual Machines recommended for use with dotCMS:

JVMSecurity Site
Oracle JavaOracle Critical Patch Updates, Security Alerts and Third Party Bulletins
Open JDKOpen JDK Security Group page

Ensure Back-End Users Have Secure Browser Software

Although you can not control the browsers used by external users to access your site, it is important that any users who can access the dotCMS backend use secure browser software when logging in to dotCMS. Therefore, as much as possible make sure your developers, administrators, and content creators are running the latest versions of their browser software, to ensure they have the most recent security patches.

The following sites provide security information and updates for the most popular browsers used with dotCMS:

BrowserSecurity Site
ChromeDownload Site (Desktop)
Google Chrome and Browser Security
FirefoxSecurity Advisories for Firefox
Internet ExplorerMicrosoft TechNet Security Center
SafariApple Security Updates

Configure dotCMS for Maximum Security

The following sections outline some of the most common areas of dotCMS configuration that should be considered when implementing security for your dotCMS site. Not all of these configurations will make sense for all sites; however you should consider each of these and understand the implications and potential vulnerabilities if you choose not to implement them.

Increase Login Security

Use the built-in dotCMS login security features to increase the security of your user login process. The following login security features can help protect against brute force password attacks, unauthorized remote access, and unauthorized use of a user account from an abandoned terminal:

  • Limit Login Failures
    • To help prevent repeated attempts to guess user passwords, minimize the value of the following property in the portal.properties file:
      auth.max.failures.limit=5
      
  • Prevent Simultaneous Logins
    • Whenever possible, ensure that each individual user has their own separate account.
    • You may then prevent users from logging into the same account from multiple locations by setting the following property in the portal.properties file to false:
      auth.simultaneous.logins=false
      
  • Automatically Time-Out User Logins
    • Automatically log users off when their session has been inactive for a period of time.
      • This helps prevent unauthorized users from accessing a valid user account after the original user has left an instance of dotCMS running.
    • To change how long users can remain inactive before being automatically logged off, modify the following property in the web.xml file:
      <session-config>
          <session-timeout>30</session-timeout>
      </session-config>
      

For more information on dotCMS Login Security features, please see the Login and Session Configuration documentation.

Configure SSL

SSL establishes an encrypted link between the client (browser) and server (dotCMS). SSL provides an important layer of security by ensuring that data transferred between the server and browser can not be intercepted and read or spoofed. Configure dotCMS to use SSL and then configure dotCMS to require SSL for all back-end logins.

Require HTTPS Access

HTTPS adds a layer of security ensuring privacy and integrity of data sent between the server (dotCMS) and the client (the browser). HTTPS is recommended for any pages which contain private information or for pages and content with restricted access.

You may configure dotCMS to only allow access via HTTPS by setting the main.servlet.https.required property in the portal.properties file to true.

# Set the following to true if this servlet can only be accessed via https.
#
main.servlet.https.required=false

Disable Features with Potential Security Risks

Ensure XSS is Disabled

By default, XSS is disabled for all classes in dotCMS except the following 3 classes:

  • com.liferay.portal.model.Portlet
  • com.liferay.portal.model.PortletPreferences
  • com.liferay.portal.model.Skin

The XSS configuration settings are contained in the portal.properties file (/dotserver/tomcat-X.x.x/webapps/ROOT/WEB-INF/classes/portal.properties). To ensure XSS is disabled in dotCMS, please review the following section of your portal.properties and portal-ext.properties files and verify that the settings match the following (default) settings:

    # Set the following to true to ensure that all persisted data is stripped of
    # XSS hacks.
    #
    xss.allow=false

    # You can override the "xss.allow" setting for a specific class by setting
    # the property "xss.allow" plus the class name.
    #
    xss.allow.com.liferay.portal.model.Portlet=true
    xss.allow.com.liferay.portal.model.PortletPreferences=true
    xss.allow.com.liferay.portal.model.Skin=true

Note:

  • These values are set by default settings, so you do not need to make any changes unless you have already modified these properties.
  • It is strongly recommended that all changes to the portal.properties file be made through a properties file extension.

Disable Groovy Sandbox

There are some known vulnerabilities in the Groovy Sandbox feature that may be exploited by malware. To prevent this, please ensure the es.script.groovy.sandbox.enabled property is set to false in the dotmarketing-config.properties file:

es.script.groovy.sandbox.enabled=false

Note:

  • This property is set to false by default, so you do not need to make any changes unless you have already modified this property.
  • It is strongly recommended that all changes to the dotmarketing-config.properties file be made through a properties file extension.

Verify that the Direct Elasticsearch REST API is disabled

dotCMS Elasticsearch REST API

dotCMS provides a secure Elasticsearch REST API to perform Elasticsearch queries against the dotCMS content store. The dotCMS API respects dotCMS Permissions, allowing users to safely perform Elasticsearch queries against your dotCMS content store, both from within dotCMS and from external applications.

Native Elasticsearch REST API

Elasticsearch also provides a native REST API; however the native Elasticsearch REST API is not secure, as it allows users to add, modify, or delete your dotCMS Elasticsearch indexes, which could corrupt or completely disable your dotCMS site.

Because of the potential security vulnerabilities it presents, the native Elasticsearch REST API is disabled by default in dotCMS, and it is strongly recommended that you leave it disabled except in the following specific circumstances:

  • You have a need to access the native Elasticsearch API directly rather than using the dotCMS Elasticsearch API (for example, to integrate a third party application, or for system management and monitoring applications running on your internal network).
  • Requests to the native Elasticsearch API are performed only from within your internal network.
  • Access to the native Elasticsearch API port from outside your network is blocked by a strong and up-to-date [firewall]#firewall].

To ensure the native Elasticsearch API is disabled, verify that the following configuration properties in the dotcms-config-cluster.properties file are disabled (as shown below):

    es.http.enabled=false
    es.http.cors.enabled=false
    es.http.port=9200
    es.http.host=localhost

Note:

  • It is strongly recommended that all changes to the dotcms-config-cluster.properties be done through a properties file extension.
  • It is extremely important that the es.http.cors.enabled property be disabled unless you are embedding the native Elasticsearch API call in another web app (cross origin).
    • Enabling this property provides “unpermissioned” access to the content index/store, allowing unauthenticated users permission to freely add, modify or remove your Elasticsearch indexes.
    • You should never embed the native Elasticsearch API in any publicly-accessible web application unless you have built a highly secure web firewall in front of the application limiting the operations that can be performed.

Manage User Accounts Securely

Improve Password Security Requirements

The dotCMS distribution is configured by default with minimal security to ease installation, evaluation, and testing of the dotCMS starter site. Therefore the default values of all password validation properties are set to the minimum security levels.

Therefore it is strongly recommended that you increase the password security settings for your site before publishing it.

For instructions on how to change password requirements, please see the Password Security Configuration documentation.

Deactivate Default Administrator Accounts

The dotCMS starter site contains two default administrator accounts with full access to your dotCMS system: Admin User and Admin2 User.

It is strongly recommended that you:

  1. Create new administrator accounts with different user names and passwords from the default accounts.
  2. Deactivate the default accounts.

This ensures that no one outside your organization knows the account names of your administrator accounts, preventing potential brute force password attacks against these accounts.

Deactivate Unused User Accounts

Ensure that all user accounts are deactivated immediately as soon as the users are no longer with your organization, or no longer need access to dotCMS.

One way to help ensure unused user accounts are deactivated is to integrate dotCMS with your enterprise user authentication using CAS or LDAP. This ensures that authentication in dotCMS automatically receives and reflects changes to your enterprise users and permissions.

Limit User and Role Permissions

Configure all users and Roles with the minimum permissions necessary for users to perform their work in dotCMS.

  • Configure permissions to give Roles only the minimum necessary permissions to perform their required tasks.
  • Assign each user only the minimum Roles required for the user to perform their work.
  • Limit the number of users with full administrative privileges.
  • Maintain permissions separately for different dotCMS servers.
    • Ensure that permissions to change backend configuration and code are limited to developers.
    • Ensure that permissions to change public-facing servers are limited to a small set of users or Roles.
  • Implement a Workflow that ensures content is reviewed before being published to your server.

Use Secure Coding Practices

Use secure coding practices to ensure that vulnerabilities are not introduced into your application through plugins or Velocity or script code on your site.

The following is a short list of important coding security practices. For a more complete list, please see the SANS SWAT (Securing Web Application Technologies) Checklist.

  • Define security requirements.
  • Educate developers about the security requirements.
  • Conduct design reviews and code reviews.
  • Don't Hardcode Credentials.
    • Never store credentials within the application code.
  • Perform security testing.

In addition, pay special attention to the following in all your application and plugin code:

Guard Against Malicious User Input

As a general rule, it is best to assume that all user input you receive is not safe. It is easy for malicious users to enter potentially dangerous content, and since user input is often a normal function of your site, it is very difficult to identify when malicious input is being entered (or has already been entered). Follow these guidelines to help protect your site against dangerous input (whether malicious or unintentional):

  • Filter user input to check for HTML tags (which might contain scripts) and Velocity code.
  • Never display unfiltered user input.
    • HTML encode any user input before displaying it, to ensure any harmful code will not be interpreted and run by the browser.
  • Never pass unfiltered user input to searches, database queries, internal methods, or external program calls.
  • Never store unfiltered user input in a database.
  • Do not rely on or trust the safety of information in the HTTP headers (Request, Response and Session).
    • Information in these headers, including user agent information, location information, and more can be spoofed.
    • Implement filters and other safeguards for cookies, query strings, and code that checks the values of these headers.
  • Do not store or display sensitive information anywhere it may be accessible from the browser (such as displayed on pages, in hidden fields, or in cookies).
    • For example, passwords should never be stored in a cookie.
  • Do not allow users to enter a path to any file in your application or on your server.
    • This helps prevent users from getting access to any other folder on your server (where they would have the permissions of the user dotCMS is installed under - see Server Permissions, above).
  • Whenever possible, validate user data using a “whitelist” approach.
    • Implement validation on each user input field.
  • When verifying or filtering user input, use a white list approach (rather than a blacklist approach).
    • Explicitly define what you will accept, and filter out everything else.
    • Do not attempt to identify or exclude malicious input.
      • It is nearly impossible to anticipate all possible malicious values, especially as your application and potential security issues change over time.

Sanitize SQL Queries

The dotCMS code has been explicitly sanitized to prevent SQL injection attacks. However if you perform any SQL queries in your Velocity code, it is possible for you to introduce vulnerabilities to SQL injection attacks if you are not careful.

The best way to prevent the possibility of SQL injection attacks in your Velocity code is to use SQL Parameter Queries. This ensures that all user entered data is sanitized and sent to the database as a parameter, so that it is not interpreted by the SQL parser and thus can not expose your code to SQL injection vulnerabilities.

Control the Use of Cookies

Cookies which store sensitive information can provide an attacker with the information they need to compromise your server or site. Therefore it is important that you are careful about what information you store in cookies, and how that information is stored.

  • Do not store any sensitive - or even potentially sensitive - information in cookies.
    • For example, never store a password in a cookie, even temporarily.
    • As a rule, do not keep anything in a cookie that, if spoofed or decrypted, can compromise your site or server.
      • Instead, store the information on a location in the server that requires authenticated access, and keep a reference to that location in the cookie.
    • If you really must store some potentially sensitive information in a cookie, make sure to encrypt it.
  • When possible, don't make cookies permanent.
    • Set cookie expiration dates the shortest practical time.
  • If possible, set the Secure and HttpOnly properties on the cookie to true.
  • Set cookie domains and paths correctly.
    • The domain and path should be set to the most restrictive settings possible.
    • Whenever possible, do not use wildcard domain scoped cookies.

Limit the Potential for DoS/DDoS Attacks

DoS (Denial Of Service) and DDoS (Distributed Denial of Service) attacks are one of the most common attacks against web sites and applications, and are very difficult to fully protect against without specialized hardware and software. However there are many types of [D]DoS attacks, and you can help minimize the impact of certain types of these attacks by following these guidelines:

  • Test and/or limit the size of all user supplied data.
    • Test the size of user input before using or storing it.
    • Restrict the size of file uploads, if appropriate.
    • Consider limiting the frequency of user requests.
  • Test and/or limit the size of all user-requested output.

Regularly Review System Logs

When a malicious or unauthorized user attempts to access or take malicious action against your system, they usually take actions which leave some kind of trace in the log files. Therefore it is important to review system logs as frequently as practical, both so you can recognize normal and abnormal log file messages, and detect any unauthorized attempts to access your system as quickly as possible so you can take addition precautions if necessary.

  • Regularly review the Security log
  • Periodically review other system log files
  • Investigate unusual logging or user behavior
    • Unsuccessful login attempts
    • Unusual login locations
    • Attempts to login to individual's accounts while they're already in use

Review Additional Security Resources

The following is a list of some additional resources which you may find of value in implementing and evaluating the security of your dotCMS sites.

ResourceDescription
dotCMS User ForumThe active dotCMS user community can help answer specific questions about implement security in dotCMS.
dotCMS SupportThe dotCMS Support team can help answer questions for Enterprise customers, and provide hot fixes for known security issues in older dotCMS releases.
Known Security Issues in dotCMSA list of security issues identified in current and previous versions of dotCMS.
Most of these security issues will be fixed in the latest dotCMS release, and
hot fixes are available for most issues from dotCMS Support.
SANS SWAT (Securing Web Application Technologies) ChecklistThe SANS SWAT Checklist provides a list of security best practices to help developers create more secure web applications.
Many of the checklist items most appropriate to dotCMS are included in this document, but it would be
very helpful to review the full checklist, especially if you are developing dotCMS plugins.