Skip to content

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 geschrieben sind, hat die Befähigung beliebige Codes mit den entsprechenden Webserver-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 damit das Ausführen von Perl-Code ermöglicht wird. Vielmehr empfehlen wir einen externen Editor.

Es wird ein anderer Ansatz 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 Controller erstellen und als Plug-in installieren.

Plug-ins und Controller sollten nur von vertrauenswürdigen Quellen installiert werden. Zusätzlich 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 offensichtlich 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 Beispiel sollten Verzeichnisse, in denen MAM Objekte hochgeladen werden, 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 Voraussetzung, 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 den Dokumentenursprung oder andere nicht öffentliche Informationen.

JSP#

Dies ist das selbe wie PHP.

Webserver-Konfiguration#

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

Deaktivieren Sie alle Module der Webserver-Konfiguration, 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, es können jedoch 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 generieren, 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 nutzergeneriertem Inhalt stehen, sollte 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#

Es wird empfohlen, unberechtigten Nutzern, die Schreibrechte auf Teile der Konfiguration haben, nicht zu erlauben, den Webserver neuzustarten. 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.