Inhalt

Folgende Komponenten spielen bei der Sicherheit von Webanwendungen eine Rolle

  • Sicherheit der Hardware
  • Bei der Verwendung von Virtualisierung, Sicherheit und Konfiguration der Lösung
  • Sicherheit und Konfiguration des Betriebssystems
  • Sicherheit und Konfiguration des Datenbankservers
  • Sicherheit und Konfiguration des Webservers
  • Sicherheit und Konfiguration von PHP
  • Sicherheit und Konfiguration der Web-Anwendung
  • Falls vorhanden: Sicherheit und Konfiguration der Firewall

Jede einzelne dieser Komponenten hat das Potenzial, bei schlechter Konfiguration das gesamte Sicherheitskonzept obsolet zu machen. Jede Software hat Fehler, die Verwendung gut gepflegter Lösungen und das kontinuierliche Einspielen von Sicherheitsupdates ist Pflicht. Zusätzlich müssen Sicherheitswarnungen zu den eingesetzten Systemen gelesen und umgesetzt werden.

Ein paar Beispiele zu den einzelnen Sicherheitskomponenten

  • Hardware: Server bringen oft eine IPMI-Schnittstelle zur Fernwartung mit. Die verwendeten Systeme haben oft Sicherheitslücken, werden aber eher selten aktualisiert. Über IPMI kann ein Angreifer einen Server komplett übernehmen, eigene Systeme booten, alle Festplatten lesen etc. D. h. IPMI sollte daher bestmöglich gesichert und darf auf gar keinen Fall über das Internet erreichbar sein.
  • Betriebssystem: Less is more – je weniger Software auf einem Server installiert ist, desto weniger Sicherheitslücken gibt es. Grafische Oberflächen von Windows oder Linux, die von remote über RDP oder VNC verwendet werden sind bequem aber auch ein unkalkulierbares Sicherheitsrisiko.
  • Datenbankserver: sehr beliebt bei Entwicklern und leider auch um schnell mal eine Web-Applikation aufzusetzen ist XAMPP – das Passwort von root ist in der Standardkonfiguration leer (XAMPP ist perfekt für Entwickler, aber für Produktivsysteme aus unserer Sicht ein NO GO!)
  • Webserver: bei der Suche nach einem schnellen Webserver stößt man schnell auf NGINX, den im Übrigen auch wir primär einsetzen. Er ist wesentlich leichtgewichtiger als der Apache und dadurch schneller, dafür fehlen einige Funktionen, wie z. B. die Unterstützung der bei Apache beliebten .htaccess-Dateien. Leider werden darüber bei vielen Web-Applikationen Zugriffsberechtigungen auf Verzeichnisse gesteuert – ohne eine manuelle Übersetzung und die Übernahme in die zentrale NGINX-Konfiguration können ggf. sensible Dateien über den Webserver ausgelesen werden. Das ist auch bei 1CRM so, siehe nächster Abschnitt.
  • Web-Anwendung: da die Webanwendung für die Interaktion mit dem Benutzer zuständig ist, bietet sie immer auch eine sehr breite Angriffsfläche. Diese sollte erst einmal so weit als möglich verkleinert werden: Keine Admin-Rechte für Benutzer, wenn möglich Zugriff auf die Applikation nur für erforderliche IP-Bereiche, Zweifaktor-Authentifizierung und die Applikation regelmäßig updaten.

In 6 Schritten die Sicherheit Ihres (1)CRM-Systems erhöhen

1. Erstellung eines gültigen Zertifikats für das CRM

Der Zugriff auf 1CRM muss auf jeden Fall über HTTPS mit einem gültigen SSL-Zertifikat erfolgen. Bei einem Zugriff ohne Zertifikat werden Zugangsdaten und personenbezogene Daten unverschlüsselt übertragen und können im Netzwerk mitgelesen werden. Die Verwendung selbstsignierter Zertifikate sorgt zwar für einen verschlüsselten Datentransfer, erzeugt aber beim Aufruf eine Warnmeldung, die der User wegklicken muss. Dieses Wegklicken erleichtert Man-In-The-Middle-Attacken. Nachdem über Let‘s Encrypt gültige Zertifikate kostenlos verfügbar sind, gibt es aus unserer Sicht, keine Ausrede mehr auf ein gültiges Zertifikat zu verzichten!

2. Normale Benutzer benötigen keine Admin-Rechte

Über die 1CRM-Administration kann das System schwer beschädigt oder sogar gelöscht werden. Aus diesem Grund hat bei uns in der Firma kein einziger Benutzer Administratorrechte. Es gibt einen separaten Benutzer, der ausschließlich für administrative Aufgaben verwendet wird. Hierdurch stellen wir sicher, dass unser 1CRM nicht versehentlich kaputt konfiguriert wird. Das Risiko sollte jeder Systemverantwortliche gegen die Zusatzkosten für eine weitere Benutzerlizenz abwägen.

3. Verzeichnisse und direkte Dateizugriffe gegen Zugriff aus dem Netz schützen

Die wichtigste Absicherung ist direkt in 1CRM enthalten, allerdings mit ein paar Fallstricken. 1CRM legt automatisch eine Datei mit dem Namen .htaccess im CRM-Hauptverzeichnis an. Diese beinhaltet Regeln für einen Apache-Webserver, um den Zugriff auf bestimmte Verzeichnisse und Dateien zu unterbinden:

# BEGIN 1CRM RESTRICTIONS - DO NOT EDIT
RedirectMatch 404 /(.*)\.log(\.[0-9]+)?$
RedirectMatch 404 ^/data/(.*)$
RedirectMatch 404 /examples/(.*)$
RedirectMatch 404 /include/(.*)\.php$
RedirectMatch 404 /modules/(.*)\.php$
RedirectMatch 404 /soap/(.*)$
RedirectMatch 404 /themes/(.*)\.php$
RedirectMatch 404 /cache/(.*)\.php$
RedirectMatch 404 /custom/(.*)\.php$
RedirectMatch 404 /files/index.html/(.*)$
RedirectMatch 404 /files/reports/(.*)$
RedirectMatch 404 /files/backups/(.*)$
RedirectMatch 404 /files/email/(.*)$
RedirectMatch 404 ^/files/upload/(.*)$

Da sich diese Datei von Zeit zu Zeit ändert (Dies ist der Stand der Version 8.6.7) sollte 1CRM auf einem aktuellen Stand gehalten werden. Falls Updates nicht zeitnah eingespielt werden können, muss die .htaccess-Datei manuell um fehlende Einträge ergänzt werden.

Beachten Sie, dass die .htaccess-Datei bei Änderungen ggf. über die 1CRM-Administration neu aufgebaut werden muss.

Vorsicht bei der Verwendung alternativer Webserver, wie z.B. NGINX oder IIS. Restriktionen aus der .htacces-Datei greifen hier nicht, d.h. die Regeln müssen auf die jeweilige Software übertragen werden. Beim NGINX funktioniert das z. B. durch Einbindung von location-Direktiven in die vhost-Konfiguration:

location ~* \.(git|log|csv|xml|pdf|zip|tsv|dat)$ {
deny all;
}
location ~ /(.*)\.log(\.[0-9]+)?$ {
rewrite ^(.*)$ /index.php redirect;
}
location ~ /data/(.*)\.php$ {
rewrite ^(.*)$ /index.php redirect;
}
location ~ /examples/(.*)\.php$ {
rewrite ^(.*)$ /index.php redirect;
}
location ~ /include/(.*)\.php$ {
rewrite ^(.*)$ /index.php redirect;
}
location ~ /modules/(.*)\.php$ {
rewrite ^(.*)$ /index.php redirect;
}
location ~ /soap/(.*)\.php$ {
rewrite ^(.*)$ /index.php redirect;
}
location ~ /themes/(.*)\.php$ {
rewrite ^(.*)$ /index.php redirect;
}
location ~ ^/cache/incoming {
rewrite ^(.*)$ /index.php redirect;
}
location ~ ^/cache/import {
rewrite ^(.*)$ /index.php redirect;
}
location ~ ^/files/backup {
rewrite ^(.*)$ /index.php redirect;
}
location ~ ^/files/email {
rewrite ^(.*)$ /index.php redirect;
}
location ~ ^/files/reports {
rewrite ^(.*)$ /index.php redirect;
}
location ~ ^/files/upload {
rewrite ^(.*)$ /index.php redirect;
}
location ~ /XTemplate/(.*)\.php$ {
rewrite ^(.*)$ /index.php redirect;
}

Hier wird kein Fehler angezeigt, sondern auf die Startseite weitergeleitet. Bei der Verwendung des IIS-Webservers müssen Redirects in der web.config gepflegt werden.

4. Backup und Upload-Verzeichnis außerhalb des Web-Roots legen

Grundsätzlich dürfen private Dateien mit vertraulichen Informationen nicht über das Netz erreichbar sein. Auch wenn im vorigen Schritt der Zugriff über den Webserver eingeschränkt wurde, sollten z. B. Backups, die 1CRM als ZIP-Dateien ablegt, immer außerhalb des Web-Roots gespeichert werden, da sie sensible Informationen in Form des kompletten Datenbankbackups und der Konfigurationsdatei inklusive Datenbankpasswort beinhalten. Mehr Informationen finden sich in unserer Dokumentation unter Backups erstellen und exportieren.

Es gibt noch weitere Pfade, die außerhalb des Web-Roots abgelegt werden können, eine Konfiguration ist momentan aber nur durch das manuelle Konfigurieren der Datei include/config/local_config.php möglich. In künftigen Versionen von 1CRM wird die Bearbeitung auch über die Oberfläche möglich sein:

Backup-Verzeichnisse außerhalb des Webroots definieren

Lesen Sie dazu auch Die richtige Backup-Strategie für Ihr CRM-System.

5. Mittels .user.ini Zugriff auf PHP-Dateien einschränken

Über die Datei .user.ini im Web-Root lassen sich PHP-Einstellungen für alle PHP-Dateien in untergeordneten Verzeichnissen vornehmen (außer PHP wird als Apache-Modul betrieben, dann sollte die .htaccess verwendet werden). So lässt sich z. B. eine PHP-Datei definieren, die vor allen anderen Skripten geladen wird:

Zugriffe auf PHP-Dateien einschränken und diese Datei vor allen anderen Skripten laden

Diese Datei lässt sich dann z. B. verwenden, um den Zugriff auf das CRM nur über definierte IP-Adressen zuzulassen. Da es sich um ein PHP-Skript handelt, das ausgeführt wird, können natürlich auch alle möglichen PHP-Funktionen verwendet werden. Die Datei _ip_restriction.php kann dann z. B. wie folgt aussehen:

<?php
$allowed_ips = [
'192.168.44.', // Intranet
'192.168.55.', // WLAN
/* RZ */
'94.150.167',
];
$allowed_scripts = [
'/removeme.php',
'/campaign_tracker.php',
'/campaign_trackerv2.php',
'/image.php',
'/WebToLeadCapture.php',
'/optin.php',
];
$allowed = false;
// check for IPs, also match IP ranges by leaving out the rightmost part.
$requestIp = $_SERVER['REMOTE_ADDR'];
foreach( $allowed_ips as $ip ){
if (strpos($requestIp, $ip) === 0){
$allowed = true;
}
}
// check allowed scripts
foreach ( $allowed_scripts as $script){
if (strpos($_SERVER['REQUEST_URI'], $script) === 0) {
$allowed = true;
}
}
if (!$allowed){
error_log('unauthorized access from ' . $requestIp . ' to ' .$_SERVER['REQUEST_URI']);
header('HTTP/1.0 403 Forbidden');
die('403 Forbidden');
}

6. Next Step: eine Web Application Firewall vor 1CRM verwenden

Eine Web Application Firewall (WAF) blockiert Zugriffe vor der eigentlichen Applikation. Hierzu verwendet die WAF einfache Muster, die in 99 % der Anfragen einer Web Applikation nicht vorkommen aber typisch für XSS (Cross Site Scripting) oder SQL-Injection-Angriffe sind.

Für die verbleibenden, legitimen Anfragen, die von den Mustern geblockt werden, müssen entsprechende Whitelists erstellt werden. Ein nicht allzu weit hergeholtes Beispiel wäre eine Firmensuche nach “Union Invest” in einem CRM, die geblockt wird, weil UNION ein SQL-Keyword ist. Wenn sichergestellt ist, dass über den Parameter keine SQL-Injection durchgeführt werden kann, wird der entsprechende Parameter für SQL-Keywords auf die Whitelist gesetzt.

An der Whitelist-Prozedur sieht man, dass es bei einem CRM, das wie 1CRM umfassend über die Oberfläche konfigurier- und erweiterbar ist, keine Out-of-the-Box WAF-Konfiguration geben kann, da hierunter wieder die Sicherheit leiden würde. Wir testen gerade auf unterschiedlichen Systemen NAXSI mit dem Ziel eine Basiskonfiguration für 1CRM anbieten zu können, die dann auf das einzelne System abgestimmt wird.

Grenzen zwischen B2B und B2C verschwimmen
CRM