Security best practices

iTop is based on PHP and its content is served by a webserver.

This page reference PHP and web-server configuration that will enhance the security of your iTop installation.

You will find here some HTTP headers to configure within your web server in order to add an extra layer of security.
Since this page try to remain simple, the headers mentioned here can often be fine tuned to be even more restrictive.

The examples below are for apache and require the mod header, but all mainstream webserver provide a way to add similar configuration.

Directories write permissions

The web server user should be allowed the write permission on the following directories, under the iTop root :

conf
data
env-*
root directory (iTop Hub connector will remove the env-production-build directory before compiling)
log

Write permission on the conf folder is only needed during the initial setup and for editing the configuration file interactively inside the application.

Secure critical directories access

The iTop packages contains configuration files for both Apache HTTPD and Microsoft IIS, see the corresponding pages

Here are file directories that must be denied to the web users :

conf : directory and all of its content
data : directory and all of its content
datamodels : allow only files having one of those extensions : css|scss|js|map|png|bmp|gif|jpe?g|svg|tiff|woff2?|ttf|eot|html
env-* : allow only files having one of those extensions : css|scss|js|map|png|bmp|gif|jpe?g|svg|tiff|woff2?|ttf|eot|html
extensions : allow only files having one of those extensions : css|scss|js|map|png|bmp|gif|jpe?g|svg|tiff|woff2?|ttf|eot|html
lib : directory and all of its content
log : directory and all of its content
setup/permissions-test-folder/permissions-test-subfolder/ : only required if your webserver doesn't use .htaccess or web.config. If access not denied, you will have a Security Warning during iTop setup (since 3.0.2 and 2.7.8)

You should also prevent directory listing.

Use HTTPS

You should serve your pages only using the https protocol.

As stated by wikipedia:

it protects against man-in-the-middle attacks. The bidirectional encryption of communications between a client and server protects against eavesdropping and tampering of the communication.

Strict-Transport-Security HTTP header

A good way to force https connection is to send the Strict-Transport-Security HTTP header.
We would recommend using this value :

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;" env=HTTPS

For more information on this header check the corresponding reference: Strict-Transport-Security - HTTP | MDN

Prevent session theft

While PHP default configuration is quite relevant from a security point of view, it can be enhanced: you should change the default value for those entries:

session.cookie_httponly

In order to prevent malicious javascript code to sniff the user's session, you should enable session.cookie_httponly (see php documentation)

you can do so either in your php.ini using session.cookie_httponly = 1, or within apache with php_flag session.cookie_httponly on.

session.cookie_secure

If you use https, you should enable this directive so cookies are only sent over secure connections, see php documentation.

session.cookie_samesite

You should enable this directive with LAX value so that session cookie would be harder to intercept, see php documentation.

Check if you are using a reverse proxy before setting this parameter !

zend.exception_ignore_args

This PHP parameter which can be set to false by default in some PHP distribution, should be set to true to avoid that in case of exception the arguments values are written in clear text in the error_log. This arguments can contain login and password to the iTop Database for eg.

HTTP headers sent by iTop

X-Frame-Options

This indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>.

See the reference : X-Frame-Options - HTTP | MDN

Sent by iTop since version 2.7.2 (N°3317, see corresponding security advisory: Admin pages are cached and can be embedded · Advisory · Combodo/iTop)
The X-Frame-Option is set for almost every pages served by iTop (header is set in the WebPage class).

In 2.7.2 it was set to denied, and beginning with 2.7.3 it is set using the security_header_xframe config parameter (default to SAMEORIGIN).

If you're using an older iTop version, you can add in your Apache configuration :

Header always set X-Frame-Options "sameorigin"

X-Content-Type-Options

This allows to opt-out of MIME type sniffing (the MIME types advertised in the Content-Type headers should not be changed).

See this reference: X-Content-Type-Options - HTTP | MDN

Implemented in iTop starting with versions 2.7.10, 3.0.4, 3.1.2 and 3.2.0 (N°4368)

Warning: this header can trigger CORB protection therefore block certain resources (HTML, JSON, XML, text).
This header can be disabled globally by using the security.enable_header_xcontent_type_options config parameter.

If you're using an older iTop version, you can add in your Apache configuration :

Header always set X-Content-Type-Options "nosniff"

Other HTTP headers

Referrer-Policy

The HTTP_REFERER header is sent by the browser on each http query, to give the previous page URL. This behavior can be changed by sending the Referrer-Policy http header from the server.

Reference documentation : Referrer-Policy - HTTP | MDN

We would advise using the strict-origin-when-cross-origin value, so that:

within the iTop the whole string is sent
only origin (scheme, host, port) is sent on cross-origin requests also on https
no referer sent on non secure destinations (http)

Sample configuration for Apache:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

Content-Security-Policy

This header will specify which resources can be loaded by the browser on each page. Its primary goal is to prevent Cross Site Scripting (XSS) and data injection attacks.

Se the reference : Content Security Policy (CSP) - HTTP | MDN

As in many other web applications in iTop unfortunately there are multiple uses of inline script and style, and we are also using the eval and setTimeout JavaScript methods.
In consequence for now we cannot get rid of allowing inline script and style (both unsafe-inline and unsafe-eval keywords), therefore CSP headers cannot be used to protect against code injection.

A solution would be to implement a strict-dynamic policy with a nonce or sha, but this would require a great amount of work. Contact Combodo if you're interested in sponsoring this development !

To mitigate injections, values set in iTop objects attributes containing HTML are filtered by default. See Rich Text Formatting limitations

Note that we have an open security policy, and public security advisories
This open process allows to quickly detect and fix security issues (including XSS) !

When implementing CSP, beware of any installed iTop extension, and check with their authors if you need to add external sources

A simple configuration for an iTop community package could be:

Header set Content-Security-Policy "default-src 'self'; frame-src 'self' www.itophub.io; img-src 'self' data: blob:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self' www.itophub.io; style-src 'self' 'unsafe-inline';

On iTop community packages, the www.itophub.io domain has to be present for the iTop Hub connector to work correctly (iFrame in the setup process, ajax operations on the newsroom)

iTop product packages includes ITSM Designer connector, but as this extension only adds a form submission to the ITSM Designer (itsm-designer.combodo.com), therefore no additional domain needs to be registered in your CSP. The iTop Hub domain (www.itophub.io) can also be removed.

Sample Apache configuration

php_flag session.cookie_httponly on
 
# only for https:
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;" 
php_flag session.cookie_secure on

Sidebar