CMS Web Application Security Overview

Introduction 

Bloomreach Experience Manager is a secure web application that follows well-established best practices to minimize security risks and prevent unauthorized access.

External parties regularly perform security audits and give feedback to Hippo about their findings. This allows us to constantly improve the CMS in this area.

Security Features

The following is an overview of some of the security features of Bloomreach Experience Manager. This list is intended to inform about the most common security issues current today, and the way they are, and/or can be configured to be, prevented in Bloomreach Experience Manager.

Clickjacking 

The clickjack attack is when a user is tricked into performing an action it did not intend to do. For instance send its user name and password to an untrusted website. This kind of attack is prevented in Bloomreach Experience Manager by not allowing the framing of the CMS in a page with a different host origin.

CSRF protection

From http://www.veracode.com/security/csrf

"Cross-Site Request Forgery (CSRF) is an attack outlined in the OWASP Top 10 whereby a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices."

Bloomreach Experience Manager CSRF protection is activated by default and prevents CSRF attacks on Wicket components by checking the Origin HTTP header for cross domain requests. It is very similar to Wicket's CsrfPreventionRequestCycleListener but slightly modified to also work behind proxies like httpd. 

If you require a domain to be able to do cross origin requests to the CMS, you can add to the cms web.xml the allowed domains for example as follows:

<context-param>
  <param-name>accepted-origin-whitelist</param-name>
  <param-value>example.com, example.org</param-value>
  <description>The allowed domains for cross origin requests</description>
</context-param>

The param-value can be a comma separated list of allowed domains. With above, every Origin header that matches example.com or example.org is allowed. Note that subdomains are also allowed. Thus for above, www.example.org is also allowed.

CRLF injection protection

From http://www.veracode.com/security/crlf-injection :

"CRLF refers to the special character elements "Carriage Return" and "Line Feed". These elements are embedded in HTTP headers and other software code to signify an End of Line (EOL) marker. Many internet protocols, including MIME (e-mail), NNTP (newsgroups) and more importantly HTTP use CRLF sequences to split text streams into discrete elements. Web application developers split HTTP and other headers based on where CRLF is located. Exploits occur when an attacker is able to inject a CRLF sequence into an HTTP stream. By introducing this unexpected CRLF injection, the attacker is able to maliciously exploit CRLF vulnerabilities in order to manipulate the web application's functions."

We wrap the response in a ResponseSplittingProtectingServletWebResponse that results in a server error when CRLF characters are tried to be written to response headers.

Session fixation

When the server identifies the session corresponding to the current request by reading the session id from the url, it makes itself vulnerable to a so called session fixation attack. Such an attack would allow an untrusted person to use a session created by a trusted person. To prevent such an attack you should disable url rewriting in your servlet container. 

In Tomcat 7 this is accomplished by adding the following setting to your web.xml:

<session-config>
  <tracking-mode>COOKIE</tracking-mode>
</session-config>

Password security

Bloomreach Experience Manager allows your organisation to enforce minimum password strength rules and password expiration policy.

Login page configuration

Also read and follow the directions in configure the CMS login page where among other things a number of security measures are detailed concerning the login page, such as preventing signin form field autocompletion, using secure cookies only, and restricting access to the cms application for to certain users only. 

Miscellaneous

• When a server side error occurs, information about CMS internals is not exposed when the application throws an error.
• By default, script tags entered through the CMS editor are stripped out.