Sicherheit

Obwohl imperia so sicher ist wie eine Webanwendung, sollten einige Sicherheitsaspekte bedacht werden.

---

Vermeidung von unautorisierten Perl Code Ausführungen

imperia kann durch die Nutzung von Perl an verschiedenen Stellen erweitert werden. Dies hat jedoch Risiken zur Folge.

Codeincludes, Flex Modules and Slots in Perl

Jeder Nutzer der Codeincludes, Flex oder Slotmodule benutzt, die in Perl geschieben sind, hat die Befähigung beliebige Codes mit den entsprechenden Websevrer-Rechten auszuführen.

Aus diesem Grund ist das hochladen solcher Perlmodule standardmäßig für alle Nutzer gesperrt. Das Feature kann durch das Setzen der Variable ALLOW_PERL_UPLOAD in den Systemkonfigurationen (system.conf) aktiviert werden. Es sollte jedoch notiert werden, dass alle imperia Nutzer mit Superuser-Rechten eine Remote Shell für das System haben.

SiteActives in Perl

imperia bietet keine wirkliche Möglichkeit an SiteActive Templates zu bearbeiten. Vielmehr können diese SiteActive Templates normale imperia Dokumente sein und könnnen somit bearbeitet werden. Doch diese Herangehensweise wird nicht empfohlen, da Redakteuren somit das ausführen von Perl-Code ermöglicht wird. Vielmehr empfehlen wir einen externen Editor.

Es wird ein anderer Anatz vorgeschlagen: Die SiteActive Templates sollten nur für den dynamischen Teil jeder Seite genutzt werden, die dann durch SSI integriert werden können.

Außerdem ist es wichtig, dass alle SiteActives, mit Perl oder HTML, eine eindeutige Erweiterung haben oder in verschiedenen Verzeichnissen separiert sind. Auf diese Weise können Sie sich sicher sein, dass nach der entsprechenden Webserverkonfiguration, der Quellcode der SiteActive Templates nicht über das Web abgerufen werden kann.

Alternativ können die SiteActives in der imperia View-Sprache geschrieben werden. Mit den imperia Views ist die Verwendung von Perl in SiteActives nicht mehr erforderlich.

Plug-ins

Zahlreiche Plug-In Interfaces ermöglichen imperia sich nahezu beliebig weiterzuentwickeln. Ab imperia 10 können Sie zur Systemerweiterung Ihre eigenen KontGrupper erstellen und als Plug-in installieren.

Plug-ins und KontGrupper sollten nur von vertrauenswürdigen Quellen installiert werden. Zusätzliche sollten Sie sich versichern, dass das site/modules Verzeichnis, genau wie alle anderen Verzeichnisse in dem Perl-Include-Pfad gegen unautorisierten Zugriff geschützt ist.

Sicherheitskonfiguration

Die Hauptkonfigurationsdatei config/system.conf hat eine zentrale Bedeutung für die Sicherheit des Systems. Jeder, der Schreibrechte für diese Dateien besitzt, kann praktisch alle Sicherheitsbeschränkungen in imperia überschreiben. Zum Beispiel kann jemand die SITE-DIR Variable manipulieren, welche die Systemsuche nach Perl-Codes in anderen Verzeichnissen durchführt.

Der Zugang zu anderen Konfigurationsdateien kann Sicherheitsprobleme nach sich ziehen, die nicht immer offentsichtlich sind.

Aus diesem Grund verweigert imperia standardmäßig die Änderung von Konfigurationsdateien über das Webinterface.

---

Vermeidung von bösartigem Inhalt

HTML Escaping

Idealerweise sollten Redakteure niemals berechtigt sein Code in Templates eintragen zu können. Praktisch maßgeblich sind JavaScript Code, SSI Direktive und PHP. Wenn SiteActive Templates redaktionell vertretbar sind, gilt dies auch für SiteActive-Code

Um Code in Seiten einzugeben sind immer Spitzklammern nötig. Aus diesem Grund sollten alle Variablen in Templates mit

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

oder

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

umschlossen werden.

Wenn Sie einen Rich Text Editor nutzen, wie den iWE, wird der Source View generell deaktiviert.

PHP

Ebenfalls sollten Nutzer bei der manuellen Wartung von PHP Seiten durch einen Escaper geschützt werden.

Außerdem sollten Redakteure nicht in der Lage sein Dokumente zu erstellen, die vom Webserver mit PHP verarbeitet werden. Zum Beipsiel Verzeichnisse, in denen MAM Objekte hochgeladen werden, sollten niemals dynamischen Inhalt aufweisen.

Eine Vorsichtsmaßnahme ist es PHP abzustellen, sofern es nicht absolut notwendig ist. Andererseits sollten PHP Dateien in einem Verzeichnis gesammelt werden, um diese einfacher zu schützen.

SSI

Das gefährliche Potenzial von SSI ist signifikant geringer als das bei PHP, unter der Bedingung, dass es mit IncludeNoEXEC aktiviert wird und somit die Ausführung von externen Kommandos verhindert wird.

Redakteure, die SSI Direktive in den Inhalt einschleusen können, haben die Möglichkeit Webserver Informationen zu erhalten, wie Dokumentenursprung oder andere nicht öffentliche Informationen.

JSP

Dies ist das selbe wie PHP.

---

Webseverkonfigurtaion

Alle Beispiele basieren auf dem Apache Webserver, da es in den meisten Installationen genutzt wird.

Deaktivieren Sie alle Module der Webserverkonfiguration, die nicht benötigt werden.

HTTPS Verwendung

Nutzen Sie HTTPS immer wenn es möglich ist.

SSI

Wenn Sie das “mod_include” im Apache Webserver nutzen wollen, müssen Sie sicherstellen, dass Sie die Nutzung von Dateien mit IncludesNOEXEC überall deaktiviert haben.

<Location />
                Order deny,allow 
                Allow from all

                Options IncludesNoEXEC
                AddOutputFilter INCLUDES .html
                </Location>

Auf diese Weise werden Dateien integriert, wie bei den SSI Includes, jedoch können keine anderen Dateien ausgeführt werden. Dies ist in der imperia Umgebung nicht nötig.

PHP

PHP sollte, falls möglich, nicht als erstes geladen werden. Falls dies nicht möglich ist, sollten sie die Ausführung von PHP in allen Verzeichnissen, die Nutzer-Content genierieren, stoppen.

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

Alternativ:

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

AllowOverride None (.htaccess)

Die Nutzung von sogenannten .htaccess Dateien, die in Verbindung mit nutzergeniertem Inhalt stehen, sollten aus Sicherheitsgründen deaktiviert werden:

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

Vermeiden von Resource Enumerations

Unter "resource enumerations" versteht man die Möglichtkeit für Eindringlinge Informationen über den Server zu erlangen, die nicht für die Öffentlichkeit bestimmt sind. Aus diesem Grund sind beispielsweise Verzeichnisaufzählungen immer abgeschaltet:

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

Der Webserver sollte so konfiguriert werden, dass er keinen Zugriff auf die Backup-Dateien erlaubt:

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

Wenn Windows^® Nutzer im Netzwerk Schreibrechte auf Serverdaten haben, gibt es Dinge wie “Copy from index.php” oder “Copy of index.php”. In diesem Fall ist es das Beste, URIs mit Leerzeichen zu verbieten:

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

Oder sämtliche Sonderzeichen:

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

Schlussendlich sollten die versteckten Dateien niemals vom Webserver ausgeliefert werden:

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

SiteActive templates können sensible Informationen enthalten und sollten niemals über das Web ausgeliefert werden. Wenn Sie den Konventionen folgen, haben die HTML SiteActives die Dateiendung “.htms” und die Perl SiteActives “.perl”.Nutzen Sie die folgende Konfiguration:

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

Es ist besser, alle SiteActives in einem Verzeichnis zu archivieren und sie global zu deaktivieren:

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

Sie sollten immer prüfen, ob die Sicherheitsmaßnahmen funktionieren. Abhängig von der Konfiguration, muss “Location” mit “Directory” ausgetauscht werden und umgekehrt.

Sudo nutzen

Unberechtigten Nutzern, die Schreibrechte auf Teile der Konfiguration haben, zu erlauben den Webserver neuzustarten ist nicht empfohlen. Die Anweisung “User oracle” beispielsweise bedeutet, dass der Webserver dann “oracle” anstatt “apache” oder “nobody”heißt. Virtuell kann jeder Sudo-Nutzer mit so einem Setup frei wählbaren Code ausführen, wie jeder Unix Nutzer der keine Root-Rechte hat.

Viele Webserver sind so konfiguriert, dass sie Konfigurationen für virtuelle Hosts aus allen Dateien in einem speziellen Ordner lesen, solange die Dateiendungen der Dateien “.conf” lauten. Wenn Sie erlauben wollen, dass der Webserver mit Sudo neugestartet werden kann, sollten Sie diese Feature nicht in der Form nutzen. Stattdessen sollten Sie eine einzelne Konfigurationsdatei speichern, die folgendermaßen aussieht:

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

Der Vorteil ist, dass in der VHost konfiguration der Nutzer und die Nutzer-ID des Webservers nicht geändert werden können.

---

imperia Konfiguration

Bitte beachten

Halten Sie imperia up-to-date! Updates sollten regelmäßig installiert werden. Nur so können Sie sicherstellen, dass bereits bekannte Sicherheitslücken behoben wurden und ihr System nicht angegriffen werden kann!

Schreibrechte

Verbieten Sie Schreibrechte für cgi-bin, site/modules. Während eines Upgrades müssen diese jedoch temporär erlaubt werden.

config.conf

Mit der config.conf Datei können Sie kontrollieren, welche Dateien über das Userinterface editiert werden können. Die config.conf und system.conf Dateien sollten nicht hinzugefügt werden, um Missbrauch vorzubeugen.

Schreibschutz auf /htdocs

Um die Sicherheit der ausgelieferten Dateien zu erhöhen stellt imperia sicher, dass Dokumente nicht unter /site oder /cgi gespeichert werden können. Seit imperia 9.1 wurde dieser Schutz um das Verzeichnis DOCROOT/imperia erweitert. Auf diese Weise werden keine Dateien unter DOCROOT/imperia, die von imperia ausgeliefert wurden, überschrieben.