»Die Kritik an Anderen hat noch keinem die eigene Leistung erspart.« Noel Coward
37 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 sogenannte Scriptkiddies, die irgendwo im Netz eine Anleitung gefunden haben, wie man in ein System eindringt, und das jetzt ausprobieren wollen. Angriffe auf Webserver richten sich in der Regel gegen drei Ziele:
- 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 weitreichend ä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! aktualisieren kann, wird weiter oben in diesem Kapitel beschrieben. Verfolgen Sie dazu auch die Nachrichtenticker auf www.joomla.org.
37.1 Angriffstypen 
Das Einfallstor für Angreifer ist in webbasierten Applikationen immer die Kommunikation zwischen Browser und Server. Dabei kann man folgende häufige Angriffstypen unterscheiden:
- SQL Injection
- Parametermanipulation
- Cross Site Scripting
- Man in the Middle
Diese Typen werden im Folgenden genauer erläuert.
37.1.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 sogenannte 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.
37.1.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önne. 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
Bei einer anderen Seite hatte der Betreiber 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.
37.1.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, auf die 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!
37.1.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.
