Suchen
Inside Wiki
Nützliche Links
phpforum.de Tipp
 
phpforum.de bei Facebook
 
phpforum.de bei Twitter
 

Zurück   PHP Forum: phpforum.de > phpforum.de Wiki > phpforum.de Wiki

PHP Wiki Dieses Wiki sammelt Lösungen, zu Problemen, welche immer wieder im Forum auftauchen.

 
 
Artikel-Optionen Ansicht
  #1  

Standard Session Sicherheit

 

Sicherheit - Inhalte

Grundlegendes


Die PHP Sessionverwaltung liefert uns die Möglichkeit, User, bzw. ihre Browser, über mehrere Seitenanfragen (Requests) hinweg wiederzuerkennen. Dazu wird von PHP serverseitig eine Session generiert in der die Daten des Nutzers gespeichert sind.
Damit die Sessions auch den Benutzern zugeordnet werden können, werden diese über eine SessionID angesprochen, die von Seitenaufruf zu Seitenaufruf weitergereicht wird.

Es gibt nur 3 Wege für diese SessionID.
  1. Übergabe der SID per Url
  2. Übergabe der SID per Cookie
  3. Übergabe der SID per Formularfeld
Die eigentlichen Sessiondaten verwaltet PHP auf dem Server. Wie das genau geschieht, wird in der php.ini eingestellt. Und auch im Script kann man die Sessionverwaltung vielfältig konfigurieren. Das Handbuch gibt gerne Auskunft dazu. Einiges davon, kommt auch in diesem Artikel zum Einsatz.
Siehe auch: Session Grundfunktion

Erkenne den Feind


Um den Sessionbetrieb schützen zu können, müssen wir die wichtigsten Angriffsarten kennenlernen.

Unbeabsichtigte Sessionübernahme


Angenommen: Die Übergabe der SID findet per Url statt und der Besucher postet einen Link auf deine Seite in einem Forum, oder sendet die Adresse einem Freund per Email. Dieser Freund, oder auch völlig Unbekannte aus dem Forum, bekommt einen Link mit anhängender SID. Man kann sich ja jetzt schon vorstellen, was passiert. Die neuen "auf den Link Klicker" führen die Session des ursprünglichen Besuchers weiter.
Auch Suchmaschinen sind in dieser Hinsicht problematisch, da sie auch solche Seiten indizieren. Dann hast du plötzlich tausende von Leuten, mit derselben SessionId auf deiner Seite.

Eine weitere Variante der versehendlichen Übernahme soll nicht unerwähnt bleiben. Es kann passieren, ist aber extrem unwahrscheinlich, dass eine SessionId doppelt vergeben wird.

Ach ja noch das Internetcaffee...
Der Besucher loggt sich auf deine Website ein, klickt und surft ein wenig. Irgendwann geht er nach Hause, vergisst aber das Fensterchen zu schließen. Jeder beliebige Gast, kann sich an den PC setzen und die Session weiterführen.

Feindliche Sessionübernahme


Diese unterscheidet sich von der vorhergehenen eigentlich nur durch die Absicht. Der Angreifer erschleicht sich die SessionId eines Besuchers und führt dessen Session weiter.
Wie kommt er da ran?
  • Spion Code auf dem Klient
  • Spion Code auf einem Router/Gateway
  • Spion Code auf dem Server
  • Aus irgendwelchen Log Dateien
  • Über die Schulter gucken und abschreiben
Wie auch immer, man kann es nicht wirklich verhindern, dass ein Fremder an eine SessionID kommen kann. Der Bereich um den Klienten herum ist für PHP unmöglich zu erreichen und abzudichten.

Der neugierige Domainnachbar


Klar, der Server Nachbar hat auch PHP und kennt ebenfalls Sessions. Für ihn ist es kein Problem sich alle Dateien im temporären Ordner (session_path) anzuschauen. Nunja, kann er sie sehen? Dann kennt er schon mal einen Haufen SessionIds von dir. Wenn er dann auch noch die Datei einsehen kann, oha, evtl. gar schreiben oje oje oje..
Das ist ein Konfigurationsproblem und sollte vom Provider behoben werden.

Der korrupte Server


Das ist die übelste Sorte. Ob es nun ein Rootkit, der Admin oder einer seiner Gehilfen ist, egal! Irgend wer/was hat Rechte erlangt die zu ALLEM freien Zugang gewähren. Sollte dieser Böses im Sinn haben, ist von PHP Seite aus, sogut wie Nichts dagegen auszurichten.

Zusammenfassung der Schwachstellen

  • Unbeabsichtigte SID Publizierung in der Url
  • Cookie auslesen (mit Hilfe von Schadcode oder Netzwerkmonitor)
  • Bezug zwischen SID und Sessiondatei
  • Auslesen der Sessiondatei
  • Fälschen der Sessiondaten

Abhilfen


Bevor es hier konkret an die Mittel und Wege geht, erst mal ein Wort zum Aufwand.
  • Was soll überhaupt in der Session gehalten werden?
  • Sind es "wichtige" Daten?
  • Lohnt der Aufwand?
Solange es nur um so unwichtige Dinge, wie einen Styleswitcher oder um die Spracheinstellung geht, lass es so wie es ist. Kommen allerdings personenbezogene Daten ins Spiel, wird es schon wichtiger. Bei einem Shop o.Ä. sollte man dann schon alle Register ziehen.
Der zusätzliche Mehraufwand in der Programmierung kostet!
  • Entwicklungszeit
  • Performance
  • Zertifikate
  • Hardware

Die SID nur per Cookie erlauben


Das ist der erste wichtige Schritt in Richtung "mehr Sicherheit"! Unbeabsichtigte Sessionübernahmen werden damit nahezu vollständig ausgeschlossen. Leider mit dem klitzekleinen Nachteil, dass Cookieverweigerer draußen bleiben.
Eine gute Strategie:
  • Bei Gästen ganz auf Sessions verzichten
  • Zum Login, nur mit aktivierten Cookies kommen lassen
  • Spätestens für einen Admin sollten Cookies Pflicht sein
PHP Quellcode:
ini_set('session.use_cookies'     ,1); // sicherlich!!
ini_set('session.use_only_cookies',1); // JA! Ohne Cookies geht hier nix!!
ini_set('session.use_trans_sid'   ,0); // bloss nicht auf 1 setzen
session_start();
if(empty($_COOKIE[session_name()]))
{
  // Cookies abgeschaltet, oder erster Zugriff
}


Verschlüsselte Verbindung


Bekannt als HTTPS oder SSL. Das ist ein erprobtes Mittel gegen Netzwerkmonitore und "Man in the middle" Attacken. Der gesammte Weg zwischen Server und Klient ist damit gut vor den Blicken unliebsamer Dritter geschützt. Der zeitliche/technische Aufwand diese Verschlüsselung zu knacken oder zu umgehen ist imens.

Häufiger Wechsel der SID


Damit bringen wir den SID Dieb in Zugzwang. Wenn wir öfter mal eine neue SID generieren, muß der Angreifer sehr Zeitnah reagieren.
PHP Quellcode:
// Programmieraufwand, nahe null
session_start();
session_regenerate_id(TRUE); // das wars schon

Leider bekommen unsere Cookieverweigerer damit ein kleines Problem. Deren Reload Button (F5) geht kaputt. Klar, nicht wirklich kaputt, allerdings: "alte Seite" gleich "abgelaufenen SID". Die Sessiondaten sind damit leider verloren, aber zum Glück nicht an den Feind.

Vorsicht ist geboten:
Wenn der Browser gleichzeitig mehrere Requests anfordert, und das tut er, dann besteht die Gefahr, dass der Browser mit veralteten SessionIDs arbeitet. Also nur in den Hauptdateien, welche HTML ausliefern, das Regenerate verwenden. Alle nachfolgenden, davon angestoßenden, Requests bitte ohne. Betroffen sind ins besondere automatische generierten Inhalte: Bilder, Flash, iFrames, JS, CSS usw.


Die zusätzliche Chance:
Wenn wir die SIDs der ganzen abgelaufenen/regenerierten Sessions eine Weile aufzeichen, können wir damit sehr schön einen Angriff erkennen. Wird eine veraltete SID benutzt, ist von einem Angriff auszugehen.

Die Browsersignatur


Einige Daten haben wir, bzw. können wir erzeugen, welche für eine Session eindeutig sein sollten.
PHP Quellcode:
// zuverlässig
$_SERVER['DOCUMENT_ROOT']
$_SERVER['HTTP_USER_AGENT'] // kann leer sein, dann aber zuverlässig leer
// eine eindeutige Kennung vielfältig als "salt" einsetzbar
define('APPLICATION_ID','w3463-dfgsdgd-564564')

// weniger zuverlässig
$_SERVER['REMOTE_ADDR'] // oder nur Teile davon
$_SERVER['HTTP_ACCEPT_LANGUAGE']
$_SERVER['HTTP_ACCEPT_CHARSET']
$_SERVER['HTTP_ACCEPT_ENCODING']
$_SERVER['HTTP_ACCEPT']

Aus diesen Daten können wir einen SESSION_SANITY_KEY (Gesundheits Schlüssel) bilden. Ändert sich dieser, dann haben wir den Angreifer identifiziert.

Der Browsermarker


Eigentlich gehört er zu der Browsersignatur, aber da wir ihn selber erstellen, bekommt er ein eigenes Kapitel. uniqid() erstellt uns einen solchen Marker. Und mit output_add_rewrite_var() können wir ihn automatisch an alle relativen Links anhängen lassen.
PHP Quellcode:
<?php
session_start();
session_regenerate_id(TRUE);

 // Browsermarker
if(empty($_SESSION['BM']))
{
  $_SESSION = array();
  $_SESSION['BM'] = uniqid();
}


if(empty($_REQUEST['BM']))
{
  // erster Aufruf, oder Angriff
}elseif($_REQUEST['BM'] !== $_SESSION['BM'])
{
  // Angriff
}else
{
  // gesund !!
}

// den Browsermarker weiterreichen
output_add_rewrite_var ('BM',$_SESSION['BM']);
?>

Es mag einem wie "SID per Url durch die Hintertür" vorkommen, ist es aber nicht. Es führt kein direkter Weg von dem Browsermarker zu den Sessiondaten.

Verschlüsseln der SID


Mit Hilfe des SESSION_SANITY_KEY können wir die SID oder den Namen der Sessiondatei verschlüsseln. Vorteil: Unser Domainnachbar/Spion kann nicht mehr 1:1 von der Sessiondatei auf die SID schließen.

Verschlüsseln der Sessiondaten


Zm Beispiel, mit Hilfe des SESSION_SANITY_KEY und des Browsermarkers können wir die Sessiondaten verschlüsseln. Damit sind die Sessiondaten auch Serverseitig recht gut geschützt/verborgen.

Der Suhosin hardening patch


Zu finden unter: http://www.hardened-php.net
Wenn irgendwie die Möglichkeit besteht, sollte man ihn installieren. Er nimmt einem einiges an Problemen ab. Zumindest auf Shared Severn bringt er ein deutliches Plus.
  • Verschlüsselung der SID
  • Verschlüsselung der Session Daten
Und vieles weiteres.

Links


« Vorheriges Kapitel   Sicherheit
  Nächstes Kapitel »

Erstellt von combie, 14.01.2008 am 15:32
Zuletzt bearbeitet von Gefrierbrand, 27.04.2011 am 21:43
9 Kommentare , 34756 Betrachtungen

Dieser Text steht unter der GNU-Lizenz für freie Dokumentation


 

Lesezeichen

Stichworte
session, sicherheit

Artikel-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.

Gehe zu
Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
xss-sicherheit ? CaptnCrunch PHP 3 23.05.2007 11:45
Sicherheit durch Session? Gewissen PHP 7 07.02.2006 17:03
Sicherheit von Session emailpoint PHP 2 05.01.2006 19:53
Session- Sicherheit barkel PHP 1 21.12.2003 19:09
Session Sicherheit MorgothP PHP 1 26.08.2003 09:19


Alle Zeitangaben in WEZ +2. Es ist jetzt 22:42 Uhr.


Powered by vBulletin® Version 3.8.8 (Deutsch)
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
Powered by NuWiki v1.3 RC1 Copyright ©2006-2007, NuHit, LLC