Configuring a web server to secure web sites powered by DX

July 19, 2017

Benjamin Papez

Jahia is the only DXP that truly empowers you to deliver personalized journeys powered by customer data Learn how here

In today’s world, where criminals are trying to hijack websites and sessions or infiltrate harmful scripts to create damage or even get access to sensitive data, it is very important to reduce risks by implementing available countermeasures.

The Open Web Application Security Project (OWASP) provides documentation and tools to help making websites more secure or to detect vulnerabilities. At Jahia it is part of our quality assurance (QA) to regularly use the OWASP Zed Attack Proxy for penetration testing in order to detect vulnerabilities in the code or 3rd party libraries and to aid the development team with information to find and close security holes. Some customers are also engaging agencies and consultants to make security assessments of their websites built with Jahia DX, which sometimes result in tickets reported to us. We are thankful for each ticket, which helps to make our products safer.

For some of the raised vulnerabilities, which are reported by consultants or automated tools, we however do not provide an out-of-the-box solution in Jahia DX, because a web server in front of Jahia DX can already take care of it. In this document we describe security related configurations for the most often used Apache web server, but also other web servers like nginx or IIS support similar settings.

ModSecurity Core Rule Set (CRS)

OWASP provides a very powerful and easily pluggable set of core rules for the ModSecurity web application firewall, which we recommend using on your Apache / IIS / nginx web servers. It provides protection against Cross Site Scripting (XSS), Session Fixation, HTTP Protocol Violations, Remote Code Execution, Path Traversal and many other attacks. It detects patterns of known attack types and blocks them.

More information about the protection, the rules and how to install them can be found at https://modsecurity.org/crs/ . Be aware that such a Web Application Firewall (WAF) can affect the performance of your web application, so you should do performance tests before going to production.

Also as ModSecurity CRS can detect false positives we highly recommend to check with thorough testing that no error is thrown before going to production. The parameter SecRuleEngine in the file /etc/modsecurity/modsecurity.conf can be set to DetectionOnly to just log the errors without blocking the requests. To prevent false positives you will either have to exclude or adapt the configuration of the related rules. You can also add your custom rules if necessary.

For instance if your website can be accessed by mobile devices using a 3G connection, they may suddenly change its IP address while moving. To prevent that this is seen as an attack you have to disable rule 981059 that detects changes in IP addresses of sessions.

SecRuleRemoveById 981059

Set security related HTTP headers

For setting secure HTTP headers there is also an OWASP project with recommendations accessible with this link: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers

Here are some of the most commonly used and recommended headers:

X-Content-Type-Options

Some browsers/clients may do MIME-sniffing in cases where a MIME type is missing or the client believes that the MIME type is not set correctly. As some MIME types represent executable content there is a security concern to that practice. That is why it is generally recommended to defend against MIME-sniffing by using the X-Content-Type-Options HTTP response header. With Apache2 one can set this with adding the module headers and the following configuration:

Header set X-Content-Type-Options nosniff

X-XSS-Protection / Content-Security-Policy

This is a HTTP response header which is not supported by Firefox, but other browsers seem to support it. The header can prevent the rendering of the page if an XSS attack is detected. With Apache2 the header can be set by using the module headers and setting with the following configuration:

Header set X-XSS-Protection "1; mode=block"

Nowadays the better option is to use the Content-Security-Policy header, which is supported by all modern browsers. However as DX is using GWT we currently cannot get rid of inline javascript, so the Content-Security-Policy for now may only unfold its strength in live browsing, when the templates are not using any inline Javascript. Alternatively one has to set the option 'unsafe-inline', which allows execution of inline scripts.
As of this writing it is an open and ongoing task to make Jahia DX support Content-Security-Policy.

X-Frame-Options

With the X-Frame-Options HTTP response header one can prevent that someone is displaying your pages within a surrounding <frame>, <iframe> or <object>, which would open the site for clickjacking attacks. As defense you need to set the following configuration in an Apache2 web server with an enabled headers module::

Header set X-Frame-Options: "sameorigin"

Strict-Transport-Security

The HSTS (HTTP Strict Transport Security) header, which is supported by all major browsers, will ensure that all communication from a browser is sent over HTTPS (HTTP Secure) protocol. This redirects HTTP requests to HTTPS and prevents HTTPS click through prompts in browsers and any man-in-the-middle attacks.

By using the headers module in Apache2 and setting the following configuration you are telling the browsers that requests for your domain and subdomains are available only over HTTPS for one year.

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains;"

Blocking brute-force login attempts or (distributed) denial of service (DDoS / DoS) attacks

Attackers may try to login to an account with trying different passwords in a short-time, which is called “brute-force login attack”, or they may try to bring down a site by sending a huge number of requests, which the servers could not handle (called Denial of Service attacks DoS or Distributed Denial of Service attacks (DDoS) if requests come from different IPs).

OWASP (see Denial of Service Cheat Sheet) and the Apache web server documentation has recommendations how to protect against DoS attacks. There are also third-party modules like mod_evasive or fail2ban. These will only work if the HTTP server is not behind a load balancer or proxy, unless the load balancer/proxy has a way to tell what IP has to be blocked.

DDoS attacks are hard to address with on-premise solutions. You will most probably have to find a 3rd party provider to protect you, like subscribing to a service from a CDN (Content Delivery Network), who offer advanced DDoS protection and mitigation.

The problem with locking out IP addresses is that it could inadvertently block large groups of users by blocking a proxy server used by an ISP or large company. Therefore for instance a better solution to block brute force login attacks would be to set a CAPTCHA field after the second bad login attempt from a client.

Prevent Server Information Leakage

If an attacker can identify the web server vendor and version, he may exploit known vulnerabilities for that server. Therefore for Apache web server you should set the following settings to disable sending too much information about the used software:

ServerSignature Off ServerTokens Prod

You should also disable all unnecessary modules and check that you are using default virtual host ports (80 and 443).

SSL configuration

A secure SSL configuration of your web server will protect you from known exploits. The following two URLs are very useful to set and check your SSL configuration: https://cipherli.st/ and https://www.ssllabs.com/ssltest/

Back