SESSION Sicherheit
Autor: Vilma Plum
eingetragen: Mittwoch, 29. Juni 2005 um 10:37 Uhr (26/2005 Kalenderwoche)
geändert: Mittwoch, 07. November 2012 um 11:19 Uhr (45/2012 Kalenderwoche)
Keywords: hijacking sicherheit session
Kategorien: PHP, IDS (PHP-ids),
Text:
session hijacking:
Es bestehen drei Möglichkeiten des Hijakcings:
1. interception:
verschlüsselte Kommunikation.
2. prediction:
kryptographisch starke pseudo-random Generatoren verwenden.
3. brute-force attacks:
effektive bit-Länge gross genug wählen, in Abhängigkeit von der Anzahl der simultanen sessions.
Diese drei Attacken können von Server-Seite geregelt werden, während die folgende fixation nur durch die Applikation selber verhindert werden kann.
session fixation vulnerability:
Anfälligkeit für vordeklarierte Session-IDs.
Schritt 1 Session setup:
Generell existieren zwei session management Mechanismen:
permissive: diese Mechanismen akzeptieren eigenmächtig erstellte session-IDs und generieren eine neue Session mit der übergebenen session-ID. (Macromedia JRun server, PHP)
strict: akzeptieren nur bekannte Session-IDs, die lokal generiert wurden. (IIS)
Für die permissiven Systeme muss der Angreifer nur eine zufällige Fallen-Session-ID generieren und diese erinnern.
In stricten Systemen wird zuerst eine tatsächliche Session mit dem Ziel-Server aufgebaut und diese session-ID wird als Fallen-Session-ID weiter genutzt. Die tatsächliche Session muss für den ganzen Attackiervorgang aktiv bleiben, diese session muss am Leben gehalten werden.
Schritt 2 Session fixation:
Die in Schritt 1 gewonnene Fallen-Session-ID wird an den Browser des Users weitergeleitet.
als URL-Argument: worldbank.com/login.jsp?session=1234
als hidden Form-Feld
als Cookie,
Die letztgenannte Methode ist der meistbenutzte Ansatz. Hierzu existieren mehrere Möglichkeiten:
1. ein client-seitiges Skript benutzen:
a. Javascript: document.cookie='sessionid=1234'
b. cross-site scripting: worldbank.com/.idc
c. persistent cookies: worldbank.com/.idc
d. domain cookies: worldbank.com/.idc
2. ein tag benutzen mit set cookie : worlbank.com/<meta%20http-equiv=Set-Cookie%20content='sessionid=1234;%20Expires=Friday,%201-Jan-2010%2000:00:00%20GMT'>
3. http-response header mit set cookie benutzen:
a. session adoption: einige Server (JRun) akzeptieren jede Session-ID.
b. Einbruch in irgendeinen host auf dem Ziel-Server.
c. Angriff auf den DNS-Server des users.
d. Netzwerkbasierte Attacke
keine vordeklarierten session IDs:
es muss jeder Login in eine gewählte Session verhindert werden. Zur Login-Zeit darf nicht auf eine vom Browser des Users angebotene Session-ID zugegriffen werden. Erst nach erfolgreicher Authentification darf vom Server eine neue Session generiert werden.
session erst nach Login: Die Generierung sollte nie zusammen mit dem Login-Form geliefert werden.
Beschränkungen des session ID Gebrauchs:
1. Session an Browser-Adresse binden.
2. Session-ID an SSL client certificate binden, jedes server-seitige Skript sollte dies zuerst prüfen.
3. Session-Zerstörung immer auf Server-Seite, nicht nur durch Log-out oder Timeout. Hierzu sollte die Funktion sessiondestroy() genutzt werden. Diese setzt keine Variablen aus dem global scope zurück, die im Laufe der Session gesetzt wurden. Dieses trifft meiner Meinung nur dann zu, wenn auch in der php.ini registerglobals enabled ist.
4. immer die Möglichkeit zum Log-out geben, damit dann die Sessions löschen, auch alte.
5. absolute Timeouts verhindern lange Session-Zeiten.
Quellcode:
if (!isset($_SESSION)) {
session_start();
}