Security

Although imperia is secure as a web application, some security aspects should be considered.

Avoid Execution of Unauthorized Perl Code

imperia may be extended in various places using Perl. This hides some risks.

Codeincludes, Flex Modules and Slots in Perl

Each user who uses codeincludes, flex modules or slots, written in Perl, has the ability to execute arbitrary code with the appropriate web server privileges.

For this reason, uploading such Perl modules is disabled by default for all users. The feature can be activated by setting the variable ALLOW_PERL_UPLOAD in the system configuration (system.conf) to a value other than 0. It should be noted, however, that all imperia users with superuser privileges have a remote shell for the system.

SiteActives in Perl

imperia does not give any genuine possibility to edit the SiteActive templates. In fact, these SiteActive templates can be normal imperia documents and can be edited. Such setup is not recommended as, with the rights to edit, a user may input Perl code that would be executed when the SiteActives are executed.

A different approach is suggested: The SiteActive templates should only be used for the generation of the dynamic part of each page, and this dynamic part can then be integrated by SSI.

Furthermore, it is important that all SiteActives, with Perl or HTML, have an unambiguous extensions or are separated in different directories. In this way, after the appropriate web server configurations, you can be sure that the source code of the SiteActive templates cannot be accessed over the Web.

Alternatively, the SiteActives can be written in the imperia view language. With imperia views it becomes unnecessary to use Perl in SiteActives.

Plug-ins

Numerous plug-in interfaces allow imperia to expand virtually arbitrarily. From imperia 10, you can also create and install as plug-ins your own controllers that can be used for system expansion.

Plug-ins and controllers should be installed only from trusted sources. In addition, make sure that the site/modules directory, as well as all other directories, is protected in the Perl include path against unauthorized access.

Security Configuration

The main configuration file config/system.conf is of central importance for the security of the system. Anyone who has write access to this file can overwrite virtually all security restrictions in imperia. For example, one can manipulate the variable SITE-DIR which will make the system search for Perl code in other directories.

The access to other configuration files can cause security problems that are not always obvious.

Because of this reason, by default, imperia does not allow configuration data to be changed via the web interface.

Avoid Generation of Malicious Content

HTML Escaping

Ideally, editors should never be allowed to enter code in templates. Practically relevant are JavaScript code, SSI directives and PHP. If SiteActive templates are editorially maintainable, this also applies to SiteActive code.

Angle brackets are always needed to insert code into pages. For this reason, in principle, all variables in templates should be escaped with:

<!--XX-TEXT:varname-->

or

<!--XX-TEXTBR:varname-->

When using rich text editors such as iWE, the source view should generally be deactivated.

PHP

Also, with manual maintenance of PHP pages, user input should be protected by an escaper.

Furthermore, editors should not be able to create documents that will be processed by the web server using PHP. For example, directories, where MAM objects will be uploaded should never have a dynamic content.

A precaution is to turn off PHP if it is not absolutely necessary. Otherwise, concentrate PHP files in a single directory, because it is easier to protect.

SSI

The threat potential of SSI is significantly lower than that of PHP, provided that it has been activated with IncludeNoEXEC, and the execution of external commands is thus prevented.

Editors, who can plant SSI directives into the content, have the possibility to obtain web server information, such as document root, or other non-public information.

JSP

This is the same as with PHP.

Web Server Configuration

All examples are based on the Apache web server, because it is used in most installations.

Deactivate all modules of the web sever configuration that you do not need.

HTTPS Usage

Use HTTPS whenever possible.

SSI

If you want or need to use the “mod_include” in the Apache web server, make sure that you have deactivated the usage of files with IncludesNOEXEC everywhere.

<Location />
  Order deny,allow
  Allow from all

  Options IncludesNoEXEC
  AddOutputFilter INCLUDES .html
</Location>

In this way files may be integrated, as with the SSI Includes, but no other files can be executed. In imperia environment this is not necessary.

PHP

PHP should, if possible, not be loaded first. If this is not possible, you should stop the execution of PHP in all directories that can generate User Content:

<LocationMatch "^/images/mam/.*\.(php[1-9]?|phtml)$">
    Order allow,deny
    Deny from all
    Satisfy All
</LocationMatch>

Alternatively:

<Directory /full/path/to/images/mam>
    <FilesMatch "\.(php[1-9]?|phtml)$">
        Order Deny,Allow
        Deny from All
    </FilesMatch>
 </Directory>

AllowOverride None (.htaccess)

The use of the so-called .htaccess files related to user-generated content should be disabled completely for safety reasons:

 <Directory /full/path/to/document/root>
    AllowOverride None
 </Directory>

Avoid Resource Enumerations

Under resource enumerations understand the ability for an intruder to gain information about the server that is not intended for the public. For this reason, for example, directory listings are always switched off:

 <Directory /full/path/to/document/root>
    Options -Indexes
 </Directory>

The web server should be configured in such a way, that it does not allow access to the backup files:

<LocationMatch "\.(bak|ori?g|tmp|swp|~)$">
    Order allow,deny
    Deny from all
    Satisfy All
</LocationMatch>

If Windows^® users have write access to the server data through the network, there are things like “Copy from index.php” or “Copy of index.php”. In this case it is best to prohibit URIs with spaces:

<LocationMatch " ">
    Order allow,deny
    Deny from all
    Satisfy All
</LocationMatch>

Or any control character:

<LocationMatch "[\x01-\x31]">
    Order allow,deny
    Deny from all
    Satisfy All
</LocationMatch>

Finally, the hidden files should never be delivered by the web server:

<LocationMatch "^\.">
    Order allow,deny
    Deny from all
    Satisfy all
</LocationMatch>

SiteActive templates can contain sensitive information and should never be delivered via the Web. If you follow the convention that HTML SiteActives have the file extension “.htms” and Perl SiteActives - “.perl”, use the following configuration:

<Directory /full/path/to/document/root>
    <FilesMatch "\.(htms|perl)$">
        Order Deny,Allow
        Deny from All
    </FilesMatch>
 </Directory>

It is better, however, to archive all SiteActives in a directory and disable it globally:

<Location /site-active>
    Order allow,deny
    Deny from all
    Satisfy All
</Location>

You should always check if the security measures work. Depending on the configuration, “Location” may have to be replaced with “Directory” and vice versa.

Using Sudo

Allowing unprivileged users to restart the web server when these users have write access to parts of the configuration is unwise. For example, the directive “User oracle” means that the web server is then called “oracle” instead of “apache” or “nobody”. Virtually every sudo user with such a setup will be able to execute arbitrary code as any Unix user other than root.

Many web servers are configured so that they read configurations for virtual hosts from all files in a specific directory, as long as the filenames end in “.conf”. If you want to allow web server restart with sudo you should not use this feature in this form. It is better this directory to store a single configuration file that looks something like this:

Include /srv/www/imperia/projekt_a.conf
Include /srv/www/imperia/projekt_b.conf
Include /srv/www/imperia/projekt_c.conf
...
User apache
Group apache

The advantage is that in the vhost configuration the user and the user ID of the web server cannot be changed.

imperia Configuration

Note

Keep imperia up-to-date! Updates should be installed regularly. Only then can you be sure that already known security vulnerabilities are fixed on your system and cannot be exploited!

Write Permissions

Forbid write permissions for the cgi-bin, site/modules. During an upgrade (micro release) they must be temporarily allowed.

config.conf

With the config.conf file, you can control which files can be edited through the user interface. The config.conf and system.conf files should not be added, in order to prevent misuse.

Write Protection on /htdocs

To increase the safety of the delivered files, imperia ensures that documents cannot be stored in the /site or /cgi directory. Since imperia 9.1 this protection has also been extended to DOCROOT/imperia. In this way no files in the DOCROOT/imperia directory, provided by imperia, will be overwritten.