CMS Web Application Security Overview - Enterprise Java Content management system - Hippo CMS

CMS Web Application Security Overview

Introduction 

Hippo CMS 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 Hippo CMS. 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 Hippo CMS.

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 Hippo CMS 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."

Hippo CMS 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 whitelisted domains for example as follows:

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

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

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>
If you use a different container than Tomcat, it might complain about this setting. In that case you have to find a container-specific way to configure the same protection.

Password security

Hippo CMS 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

CMS Web Application Security Overview

Introduction 

Hippo CMS 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 Hippo CMS. 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 Hippo CMS.

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 Hippo CMS 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."

Hippo CMS 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 whitelisted domains for example as follows:

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

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

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>
If you use a different container than Tomcat, it might complain about this setting. In that case you have to find a container-specific way to configure the same protection.

Password security

Hippo CMS 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