Skip to content

Security

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

Avoid unauthorized Perl code execution#

imperia can be extended in a number of ways by using Perl. However, this involves risks.

Codeincludes, Flex Modules and Slots in Perl#

Any user using code includes, flex or slot modules written in Perl is able to execute any code with the appropriate web server permissions.

For this reason, uploading such perl modules is blocked by default for all users. The feature can be enabled by setting the variable ALLOW_PERL_UPLOAD in the system configurations (system.conf). However, it should be noted that all imperia users with superuser privileges have a remote shell for the system.

SiteActives in Perl#

imperia does not offer a real way to edit SiteActive templates. Instead, these SiteActive templates can be normal imperia documents and thus can be edited. However, this approach is not recommended as it allows editors to execute Perl code. We recommend using an external editor.

A different approach is suggested: SiteActive templates should only be used for the dynamic part of each page, which can then be integrated through SSI.

It is also important that all SiteActives, with Perl or HTML, have a unique extension or are separated in different directories. In this way, you can be sure that after the appropriate web server configuration, the source code of the SiteActive templates cannot be retrieved over the web.

Alternatively, SiteActives can be written in the imperia View language. With imperia views, you no longer need to use Perl in SiteActives.

Plug-ins#

Numerous plug-in interfaces allow imperia to develop itself further almost arbitrarily. Starting with imperia 10 you can create your own controllers and install them as plug-ins.

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

Security configuration#

The main configuration file config/system.conf has a central meaning for the security of the system. Anyone who has write access to these files can override virtually all security restrictions in imperia. For example, someone can manipulate the SITE-DIR variable, which performs the system search for Perl codes in other directories.

Accessing other configuration files can cause security problems that are not always obvious.

For this reason, imperia refuses to change configuration files via the web interface by default..

Avoid malicious content#

HTML Escaping#

Ideally, editors should never be allowed to enter code in templates. In practice JavaScript code, SSI directive and PHP are decisive. If SiteActive templates are acceptable from an editorial point of view, this also applies to SiteActive code.

To enter code into pages you always need pointed brackets. For this reason, all variables in templates should be enclodes with

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

or

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

If you use a rich text editor, such as the iWE, the source view is generally deactivated.

PHP#

Users should also be protected by an escaper when manually maintaining PHP pages.

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

A precaution is to turn off PHP unless it is absolutely necessary. On the other hand, PHP files should be collected in a directory for easier protection.

SSI#

The dangerous potential of SSI is significantly lower than that of PHP, assuming that it is enabled with IncludeNoEXEC and thus prevents the execution of external commands.

Editors who can introduce SSI directive into the content have the ability to obtain web server information, such as document origin or other non-public information.

JSP#

Same as PHP.

Webserver configuration#

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

Disable any web server configuration modules that are not needed.

HTTPS usage#

Use HTTPS whenever possible.

SSI#

If you want to use the "mod_include" in the Apache web server, you must make sure that you have disabled the use of files with IncludesNOEXEC everywhere.

    <Location />
         Order deny,allow 
         Allow from all

         Options IncludesNoEXEC
         AddOutputFilter INCLUDES .html
    </Location>

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

PHP#

If possible, PHP should not be loaded first. If this is not possible, you should stop PHP execution in all directories that 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 so-called .htaccess files associated with user-generated content should be disabled for security reasons:

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

Avoid resource enumerations#

"Resource enumerations" means the possibility for intruders to obtain information about the server that is not intended for the public. For this reason, directory enumerations, for example, are always switched off:

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

The web server should be configured in 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 on the network have write access to server data, it is possible to do 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 all special characters:

    <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 over the web. If you follow the conventions, HTML SiteActives will 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 to archive all SiteActives in one directory and deactivate them globally:

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

You should always check that the safety measures are working. Depending on the configuration, "Location" must be replaced with "Directory" and vice versa.

Using Sudo#

It is recommended to prevent unauthorized users who have write access to parts of the configuration from restarting the web server. For example, the "User oracle" command means that the web server will be named "oracle" instead of "apache" or "nobody". Virtually, any Sudo user with such a setup can execute arbitrary code like any Unix user without root privileges.

Many web servers are configured to read virtual host configurations from all files in a special folder as long as the file extensions of the files are ".conf". If you want to allow the web server to be restarted with Sudo, you should not use this feature. Instead, you should save a single configuration file that looks 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. This is the only way to ensure that already known security vulnerabilities have been fixed and that your system cannot be attacked!

Write permissions#

Prohibit write permissions for cgi-bin, site/modules. However, during an upgrade, these must be allowed temporarily.

config.conf#

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

Write protection on /htdocs#

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