PHP-Filter für den Eigengebrauch

Teil 7: Sicherheit bei PHP: Bereinigen von Daten durch eine Web-Applikation

Filter sicher anwenden

Die korrekte Filterung aller Eingaben und auch die Nutzung von https-Verbindungen sind zwar löblich, doch alleine damit lässt sich das Sicherheitsproblem nicht in den Griff bekommen.

Der schwache Punkt in dem Sicherheitskonzept besteht in der Aufbewahrung der Sitzungsdaten. Jede Applikation sollte die Session-Daten in einem eigenen Pfad statt in einem gemeinsam genutzten Verzeichnis speichern.

Der Name und der Ablageort sollten nicht leicht zu erraten sein, also nicht etwa /tmp/application1 und /tmp/application2/. Das standardmäßig verwendete /tmp-Verzeichnis stellt keinen idealen Ablageort dar, denn es ist aufgrund liberal gesetzter Zugriffsrechte leicht zugänglich.

Stattdessen gilt es, applikationspezifische Verzeichnisse mit nicht-trivialen Namen zu wählen. Die Zugriffspfade sollten mittels ini_set('session.save_path') gesetzt werden. Die Zugriffsrechte sollten so restriktiv vergeben sein, dass sich Applikation 1 und 2 die Sessiondaten auf keinen Fall gegenseitig auslesen können.

Filter-Sicherheit bei Shared Hosting

Die sichere Implementierung von Web-Applikationen scheidet auch mit PHP-Filtern auf einem Shared-Hosting-Server kategorisch aus. Stattdessen sollte ein dedizierter Server zum Einsatz kommen.

Dadurch kann der httpd-Dämon jederzeit neu gestartet und bestehende Umgebungsvariablen frei konfiguriert werden. Laufen eCommerce-Transaktionen mit https über einen Shared-Hosting-Server, so besteht dagegen die Gefahr, dass die Daten von anderen Anwendern auf demselben Server eingesehen oder über kompromittierte Skripte anderer Benutzer aus dem Web heraus modifiziert werden können - sicherlich keine empfehlenswerte Lösung.

Session-ID-Hijacking

Außerdem gilt es, User-Space-Session-Handler zu vermeiden, denn diese sind aufgrund sogenannter Session Race Conditions verwundbar. Unter Session Race Conditions versteht man einen Systemfehler, der das Resultat vom Timing bestimmter Ereignisse abhängig macht.

Mehrere ungefähr zeitgleich ablaufende Sessions können sich zufällig oder durch gezielte Manipulation gegenseitig beeinflussen. Das nicht immer beeinflussbare Timing macht den Unterschied zwischen sicheren und verwundbaren Transaktionen aus.

Abhilfe bei Session Race Conditions schafft nur das systematische Verschlüsseln der Session-Daten mit einem applikationsspezifischen Code. Binden Sie hierzu eine jeweils einmalige und vorzugsweise zufällige Applikationskennung für die jeweilige Session ein, zum Beispiel in der Art:

if ((string)$_SESSION['application']
!== 'application1') die();

Auf diese Weise würden das Szenario 1 und 2 unmöglich gemacht, da die Session-Cookies zwischen Applikation Nr. 1 und Nr. 2 zueinander inkompatibel sind.

Gleichgültig, ob man die in PHP eingebauten oder verbesserte eigene Filter verwendet, kann man auf die Resultate nur dann vertrauen, wenn die Session-ID nicht kompromittiert wurde. Applikationsspezifische Session-IDs, Pfade zum Abspeichern der Sitzungsdaten und der Einsatz dedizierter Server stellen wichtige Voraussetzungen dar, um den eingesetzten PHP-Filtern vertrauen zu können. Leider gibt es zu viele Szenarien, um PHP-Sessions zu kompromittieren und damit den praktischen Wert von PHP-Filtern infrage zu stellen.

Stellen wir uns nun vor, dass ein bereits eingeloggter Anwender, der durch die Web-Applikation bereits authentifiziert wurde und der eine gültige Session-ID zugewiesen bekam, beschließt, sein Passwort zu ändern.

Es kann ein gutwilliger, weil lediglich vergesslicher, eCommerce-Kunde oder aber ein böswilliger Hacker sein, der die Sitzung soeben entführt hatte. Man sollte aus diesem Grunde niemals das Ändern des Passworts zulassen, ohne das alte und zuletzt gültige Passwort eingeben zu lassen.

Insbesondere sollte man tunlichst darauf achten, einem Anwender, der sich lediglich durch eine Session-ID ausweist, niemals sicherheitskritische Daten anzuzeigen. Anstatt die Kreditkarten-Nummer bei der Übersichtsanzeige der Bestelldaten im Klartext anzuzeigen, sollte man dem Benutzer stattdessen nur die letzten vier Ziffern präsentieren:

xxxx-xxxx-xxxx-3456

Möchte ein Anwender sich erneut einloggen, sollte die Web-Applikation mittels

session_regenerate_id()

immer eine frische neue Session-ID erzeugen, zum Beispiel

session_start();
$alte_sessionid = session_id();
session_regenerate_id();
$neue_sessionid = session_id();
echo "Alte Session-ID: $old_
sessionid<br />";
echo "Neue Session-ID: $neue_
sessionid<br />";
print_r($_SESSION);

Ein potenzieller Hijacker, der die Session-ID missbrauchen möchte, wird die Session-ID voraussichtlich vor dem Einloggen einrichten. Wurde die Session-ID neu generiert, so wird das Login des Hackers abgelehnt.

Mehr lesen

Chronologische Liste und Netflix-Links -

Neuerscheinungen in der Übersicht -

Vorschau auf Film- und Serien-Highlights -

Mehr zum Thema

Webdesign

Adobe Illustrator wird im Webdesign immer beliebter. Wie Sie das Tool richtig einsetzen, erfahren Sie hier.
Facebook

Was sind die Implikationen für Unternehmen und Endanwender bei Facebooks neuer Suche Graph Search?
Online-Recht

Allgemeine Geschäftsbedingungen liest sich niemand gerne durch. Sie sind jedoch notwendig und äußerst sinnvoll. Worauf sie achten sollten.
Online-Recht in der Cloud

Dateien werden immer häufiger in der Cloud bereitgestellt. Rechtlich ist das jedoch durchaus problematisch. Wir klären über das Urheberrecht in der…
E-Commerce-Logistik

Für den Erfolg eines Online-Shops sind zahlreiche Faktoren verantwortlich. Neben Produktvielfalt und Darstellung der Waren gehört auch die Logistik.