18.6 Sicherheit 

Sobald Ihr Rechner mit dem Internet verbunden ist, müssen Sie damit rechnen, dass ungebetene Gäste versuchen, sich an Ihren Daten zu vergreifen. Dabei handelt es sich in den wenigsten Fällen um echte Hacker oder Cracker, sondern vielmehr um so genannte Scriptkiddies, die irgendwo im Netz eine Anleitung gefunden haben, wie man in ein System eindringt und das jetzt ausprobieren wollen. Ziele eines Angriffs kann man bei Webseiten generell auf drei Ebenen festmachen:

Seiteninhalt. Es wird versucht, den Inhalt einer Homepage zu verändern und eigene Botschaften einzuschleusen.

Software. Das Programm, das eine dynamische Seite steuert, wird vom Missetäter verändert.

Rechner. Es wird versucht, über die Software den Rechner, auf dem die Webapplikation läuft, unter Kontrolle zu bringen. Diese Art von Angriff ist die gefährlichste. Falls sie erfolgreich ist, kann der Angreifer Ihren Computer weit reichend ändern und als Basis für weitere Angriffe auf andere Computer nutzen.

Absolute Sicherheit vor Angriffen wird man niemals garantieren können. Es gibt jedoch eine Reihe von Maßnahmen, um das Risiko zu minimieren. Die wichtigste ist: Halten Sie Ihre Software, also Webserver, PHP, MySQL und Joomla! auf dem neuesten Stand. Wie man Joomla! updaten kann, wird weiter oben in diesem Kapitel beschrieben. Verfolgen Sie dazu auch die Nachrichten-Ticker auf www.joomla.org bzw. www.mamboserver.com.

Das Einfallstor für Angreifer ist in webbasierten Applikationen immer die Kommunikation zwischen Browser und Server. Dabei kann man einige häufige Angriffstypen unterscheiden.

18.6.1 SQL Injection 

Nehmen wir an, Sie verwenden ein Login-Formular, das die Authentifizierung mittels einer Datenbankabfrage durchführt. Der PHP-Code sieht folgendermaßen aus:

$query = "SELECT * FROM users WHERE username = '"
        .$_POST['username'].'"';
$result = mysql_query($query);
if (mysql_num_rows($result) > 0) $auth = true
else $auth = false;

Es wird also in der Datenbank nachgesehen, ob der Username existiert. Ist das der Fall, wird eine Variable $auth, die den Autorisierungsstatus festlegt, so gesetzt, dass der Zugriff gewährt wird. Stellen Sie sich nun vor, Sie sind ein bösartiger Angreifer. Natürlich geben Sie keinen gültigen Usernamen ein, da Sie ihn ja nicht kennen. Da Sie findig sind, versuchen Sie, das SQL-Statement zu manipulieren. Sie geben also diese Zeichen ein:

nix' OR '' = '

Wenn das SQL-Statement nun zusammengesetzt wird, so wird diese Abfrage gestartet:

SELECT * FROM users WHERE username = 'nix' OR '' = ''

Da die zweite Bedingung in der WHERE-Klausel immer wahr ist, werden wir im System angemeldet.

Ein ähnlich gelagerter Fall ist die so genannte »Command Injection«, die möglich ist, wenn das Skript auf dem Server beispielsweise mittels exec ein Betriebssystemkommando ausführt, das direkt Parameter aus den übergebenen Formulardaten übernimmt.

Um solche Angriffe zu verhindern, müssen Sie bei der Programmierung sorgfältig darauf achten, dass die übergebenen Daten auch wirklich dem entsprechen, was erwartet wird, und auf keinen Fall SQL-Statements oder Kommandos enthalten.

18.6.2 Parametermanipulation 

Diese Art des Angriffs macht sich ungeschützte Parameter einer Seitenabfrage zunutze. Die Gefahr geht dabei davon aus, dass Daten, die sicherheitsrelevant sind, in diesen Parametern gespeichert werden, oft aus dem falschen Glauben heraus, dass man diese nicht manipulieren könnte. Zwei Beispiele, die so schon vorgekommen sein sollen, mögen dies verdeutlichen:

Mittels POST-Parameter

Eine Seite (nicht Joomla!) hatte die Mail-Adresse, an die eine Anfrage gesendet werden sollte, nicht auf dem Server, sondern direkt in ihrem Kontakt-Mail-Formular in einem <hidden>-Feld gespeichert.

<form action="mail.php" method="POST">
   <input type="hidden" name="an" value="admin@seite.de">

Dies wurde von einem findigen Spammer ausgenutzt, der die Adresse aus diesem Feld einfach austauschte und so eine Menge unerwünschter E-Mails über diese Seite – und deren Namen – verschickte.

Mittels Cookie

Eine andere Seite hatte zur Erleichterung der Kommunikation die Zugriffsparameter des Nutzers in einem Cookie auf seinem Rechner gespeichert. Das sah in etwa so aus:

Cookie: admin=no; time=10:00;

Es wurden also der Adminstatus und der letzte Zugriff (zur Sicherheit) protokolliert. Cookies sind allerdings nur Textdateien auf dem Computer. Ein nachfolgender schlitzohriger Benutzer änderte also einfach die beiden Werte in

Cookie: admin=yes; time=13:00;

und schon hatte er Zugriff auf die Seite. Und das auch noch mit Administratorrechten!

Eine mögliche Lösung für Probleme dieser Art ist, alle sicherheitsrelevanten Daten auf dem Server mittels Sessions zu verwalten, die auf jeden Fall sicherer sind als die vorgestellten Methoden.

18.6.3 Cross Site Scripting (XSS) 

Mit dieser Methode wird weniger der Webseite selbst als vielmehr ihren Usern geschadet. Der Angreifer versucht, bösartigen Code, beispielsweise in JavaScript, auf der Seite zu platzieren, der den User dann dazu bringt, Daten preiszugeben oder eine bestimmte Seite aufzurufen. Sehen wir uns das einmal genauer an. Der bösartige Code soll nur ein Hinweisfenster sein:

<script>alert ("Ich bin böse")</script>

Ein Angreifer hat zwei grundlegende Möglichkeiten, diesen Code zu platzieren. Erstens kann er versuchen, ihn in Foren, Gästebücher, Seiteninhalte etc. einzuschleusen, zu denen er Zugriff hat. Ruft der nichts ahnende User eine dieser Seiten auf, wird der Code ausgeführt.

Zweitens kann der Code über eine URL eingeschleust werden. Häufig werden Usereingaben beispielsweise auf Bestätigungsseiten noch einmal ausgegeben. Der Angreifer kann nun eben so eine URL auf der Seite platzieren. In Joomla! werden beispielsweise Rückmeldungen an den Benutzer auf diese Weise erzeugt. Keine Angst, Joomla! filtert hier bösartigen Code. Der Mechanismus kann dennoch benutzt werden, um den Besucher übel zu beschimpfen:

http://localhost/joomla/index.php?mosmsg=Sie+sind+wohl+doof

Wird diese URL aufgerufen, so steht über dem Content-Bereich »Sie sind wohl doof«.

Die Gegenmaßnahme ist auch hier wieder die sinnvolle Filterung der Eingaben. Lassen Sie auf keinen Fall <script>-Tags in irgendwelchen Foren zu!

18.6.4 Man in the Middle 

Eine Gefahr für die sichere Kommunikation zwischen Client und Server stellt immer der Mitleser dar, der sich zwischen die beiden stellt und die Botschaften, die ausgetauscht werden, abhört und unter Umständen manipuliert. Aufgrund der Natur des Internets kann man diese Mithörer nie ausschließen, da die Informationspakete auf dem Weg zwischen den beiden Endpunkten über viele Computer laufen.

Dies verdient insbesondere deshalb unsere Aufmerksamkeit, weil Zugangsdaten wie Passwörter zwar im Browserfenster maskiert werden, bei der Übertragung jedoch im Klartext gesendet werden. Ein Mitleser kann sie also sehr leicht abfangen und für seine Zwecke missbrauchen.

Die einzig sichere Variante, diesem Problem zu entkommen, ist, eine verschlüsselte Verbindung zu verwenden. Dies ist über das HTTPS-Protokoll möglich. Um wirklich sicherzugehen, benötigen Sie dafür allerdings eine feste IP-Adresse und ein Vertrauenszertifikat. Das ist durchaus mit einigen Kosten verbunden.

18.6.5 Vorbeugende Maßnahmen 

Viele der besprochenen Sicherheitsprobleme lassen sich leider nur durch eine saubere Programmierung beheben. Selbst da können sich noch Fehler einschleichen. Daher möchten wir Sie an dieser Stelle nochmals ermuntern, immer die neuesten Updates einzuspielen, besonders, wenn diese als sicherheitskritisch eingestuft werden.

Es gibt eine Komponente, die Ihnen hilft, Ihre Systemumgebung auf Sicherheitslücken zu testen: Mambo Security Check. Leider läuft diese Erweiterung nur mit PHP 4, eine Portierung auf PHP 5 wurde in Aussicht gestellt.

Sie finden die Erweiterung auf der CD im Verzeichnis Erweiterungen/Security_ Check. Installieren Sie die Datei com_securitycheck_v095.zip im Backend als Komponente. Im Menü Components · Mambo Security Check finden Sie die beiden Unterpunkte Check Environment, mit dem die Systemumgebung überprüft wird, und Check FileSystem, das die Dateiberechtigungen durchgeht. Die Überprüfung starten Sie jeweils mit dem Scan-Button.

Wie Sie aus der Überprüfung des Dateisystems schon folgern können, sind falsch gesetzte Zugriffsberechtigungen ein mögliches Sicherheitsrisiko. Nun ist es so, dass einige Dateien und Verzeichnisse von Joomla! beschreibbar sein müssen. Eine Liste dieser Verzeichnisse finden Sie in Kapitel 2, Installation. Die anderen Verzeichnisse sollten nur von Ihnen beschreibbar sein, so dass Sie die Rechte mit dem Befehl chmod auf 755 für Verzeichnisse und 644 für Dateien setzen sollten. Damit können die Files von allen gelesen, aber nur vom Besitzer geändert werden. Die Berechtigungen können Sie sehr einfach mit dem Joomla!-Explorer setzen.

Darüber hinaus können Sie über diverse Maßnahmen verhindern, dass ungebetene Gäste auf Ihren Seiten Bearbeitungen vornehmen können. Da dies auch im Zusammenhang mit Spam interessant ist, verweisen wir Sie dazu auf das folgende den folgenden Abschnitt.