Securing WebApp

December 13, 2012 by Ivo Timmermans   Comments (2)

, , ,

While we take care that the WebApp contains no programming flaws that can reduce security, there are a few things that you, as system administrator, can do to improve security. The most obvious one is to only allow access to WebApp when using SSL, but there is more. For this article, we will assume that you serve WebApp using Apache, but other HTTP servers have similar options.

Use TLS/SSL, get an official certificate
Anyone knows you should use SSL, and of course you can run a web server using a self-signed certificate, and you can even distribute your CA certificate to your users. However, the additional benefits of using a trusted certificate authority that is accepted by operating system, browser and mobile phone vendors are not just ease of use.

Without additional configuration, apache will publish WebApp on both HTTP and HTTPS. To only allow access to WebApp when the user uses SSL, you can add SSLRequireSSL in the virtual host serving WebApp.

Disable SSL version 2
Version 2 of the SSL protocol uses weak ciphers to communicate. You can tell Apache to never use them by adding SSLProtocol All -SSLv2 to your configuration.

php_flag session.cookie_secure on
WebApp needs a connection to the server after logging in, and it will pass along a cookie to the server so that the server knows which session to use. The browser is the one that decides whether or not to send this cookie to the server. Telling the browser that this cookie should only be sent over an SSL connection makes it harder to retrieve the cookie. The effect is that it becomes harder for an attacker to steal the cookie and access the user's data.

To make sure that this flag is set for WebApp, you can enable a new check that was introduced in WebApp 1.2.2: CONFIG_CHECK_COOKIES_SSL. This is by default set to false, but if you set it to true, WebApp refuses to load if the session.cookie_secure flag is not set to on.

php_flag session.cookie_httponly on
If, for some reason, malicious code is injected into the WebApp (for example, using a browser plug-in), then the browser would normally make this cookie available to the injected code. This would allow an attacker to send the cookie somewhere else. If you set this flag, then this will not happen - the cookie is only sent to the server in a regular request. This flag is only available if you use PHP 5.2 or higher (RedHat 5 ships with PHP 5.1).

To make sure that this flag is set for WebApp, you can enable a new check that was introduced in WebApp 1.2.2: CONFIG_CHECK_COOKIES_HTTP. This is by default set to false, but if you set it to true, WebApp refuses to load if the session.cookie_httponly flag is not set to on.

apache user
In the unlikely case that there is an error in the server-side code, for example a plugin that does too little input validation, you can limit the amount of damage that can be done by running apache as a separate user. This is usually already configured on your operating system, but it's easy to do.

You can also consider running the virtual host that serves WebApp as a separate user. This is useful especially if you have multiple web sites besides WebApp. In that case, the other websites won't be able to access files that are being managed by WebApp (which is mainly session files or attachment temporary files).

The DEFAULT_SERVER setting in config.php allows you to use either a unix socket or a http(s) URL. If you pass in a unix socket, then you must make sure that the user that's running apache is not listed in the "local_admin_users" setting of Zarafa's server.cfg. On the other hand, if you run multiple (non-Zarafa related) services on the same host, you probably want to set "allow_local_users" to "no" in server.cfg, and use a https socket. And of course, if you have Zarafa running on a separate machine from the web server (which is recommended if you can afford it), you must use http or https anyway.

The short story is: there is no "safest" default value here. You should pick one that suits your needs.

Apparmor and SElinux
If you want to go even further, you can specify exactly which files or network connections are allowed by apache and Zarafa. I'm open to input on hammered-down configuration files for SElinux or Apparmor. We will get back on this in a later post.

An official SSL certificate does not increase the security on a technical level at all. Some of these certificate authorities (I recently remember to a Dutch one being in the news) are even less secured as some would expect. All you get by an official certificate is a paid trust chain in the browser, which does not really increase security.

If you suggest official SSL certificates, you also should suggest introducing DNSSEC to avoid man-in-the-middle attacs which are possible with SSL and hacked/broken certificate authorities, too. By the way: Each time you log into a default installation of the WebApp, your feedback plugin does a backconnect to via HTTPS, while is not secured via DNSSEC right now.

Additionally various of the certificate authorities create SSL certificates with vulnerable MD5 algorithm or weak key sizes or have a weak certificate chain. Some admins out there even create certificate signing requests (CSRs) for submission to the certificate authority with a weak key size (less than 2048).

Did you ever evaluate HTTP Strict Transport Security alternatively to "SSLRequireSSL"?

Disallowing SSLv2 is a good thing in general, but this is the default in nearly every current Linux distribution for years now. Instead you really should advise people to use at least TLS 1.1 or even better: TLS 1.2. And if you can not run this, because your Linux distribution still ships an old version of OpenSSL, you should recommend a good SSLCipherSuite (like "RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL") to also exclude weak ciphers or minimize the risk of already known SSL/TLS protocol issues - especially if your users may not run latest browsers and thus also not support TLS 1.2.

Another thing in the SSL/TLS world which is often forgotten by less knowledged administrators is the trust chain: Use SSLCACertificatePath (c_rehash from OpenSSL is your friend) or SSLCACertificateFile. I already have seen lots of Zarafa setups out there lacking the certificate trust chain. Note, that it still often works in nearly all browsers, even if you forget to configure this properly.

I wonder if you ever did things like Apache suEXEC or Apache MPM Worker with PHP in real life...however this brings me to my next point:

Why do you want to get later to SELinux? That work has been already done IIRC 1.5 years ago by Matěj Cepl, Miroslav Grepl and Daniel Walsh. Zarafa will work like a charm with SELinux enabled in e.g. Red Hat Enterprise Linux 5 and 6 (respectively also CentOS) and all current Fedora releases (like Fedora 14+). There is no need to re-invent the wheel. Ivo, I will invite you next time personally to my SummerCamp talk ;-)

With SELinux you even can cover one or the other operating system (library, service or similar) security issue, however, securing WebApp also requires a proper maintained system that regulary gets all security updates applied. And once the end-of-lifetime of the specific Linux distribution took place, an upgrade to a supported version needs to happen. You can't believe how many unsupported systems are out there or systems that run old software versions which are vulnerable. That is also securing WebApp!

If I was able to catch your interest in following up the hardening or if you would like to get your own Zarafa installation cross-checked regarding my proposal and thoughts, just contact me.

Robert Scheck 494 days ago

Robert, many thanks for your detailed response. A blog post like this can of course never be fully complete while still covering the details of all operating systems, so that's why it's more like a list of pointers. You really could write a book on only this topic :)

Ivo Timmermans 492 days ago