[Powie\"s PSCRIPT Forum] Session Hijacking Vulnerability

Session Hijacking Vulnerability
in
Powie\'s PSCRIPT Forum
Summary
Product             Powie\'s PSCRIPT Forum
Version             <= 1.26
OS affected         All with PHP and mySQL
Remote Exploit      Yes
Risk Lvl            Critical
Vendor              Thomas \'Powie\' Erhardt
                   http://www.pscript.de/
                   Informed
Introduction
The PSCRIPT Forum is a Bulletin Board, similar to phpBB or Phorum. The
PSCRIPT Forum starts for every visitor a php session 
 and stores some
userdata in this. An attacker can hijack a session, only by knowing 
(guessing or stealing) the Session ID.
More Details
PHPs Session Mechanism stores a 32-byte-Session-Id by default in a 
cookie or in the URL as GET-Parameter (as fallback). If the users sends
his Session ID to an attacker (looking to a picture on an foreing host 
[HTTP_REFERER], sending an link with the Session ID to a friend, for
example), an attacker steals the Session ID-Cookie (by XSS), or the
users shares his machine (or his account) with other people, it\'s easy
to hijack his account.
Risk Level
Critical. Users can post pictures and external links to the forum and
read the HTTP_REFERER-Header (if cookies are deactivated). There are
some Cookie- and XSS-Vulnerabilities in the PSCRIPT Forum, so that 
Cookies can be easily read.
Vendor
The Vendor is informed.
Notes
 
http://de.php.net/manual/en/ref.session.php
See Also
http://shiflett.org/talks/oscon2004-securing-php-sessions/
http://shiflett.org/articles/the-truth-about-sessions

[combat]

Wenn ich jetzt wüsste, was man dagegen tun kann, würd ich mich gleich an die Arbeit machen.

Es gibt mehrere Ansätze (Hint: \"See Also\").
I.) Eigenschaften des Clients werden in der Session abgelegt und 
verglichen. Hierbei wird z.B. die IP, Accept-Encoding, der Hostname, 
oder sost ein Detail in der Session gespeichert und bei jedem Aufruf 
verglichen. Ist aber auch nicht sicher, da man sich mindestens einmal 
auf den Client verlassen muss (damit ist es dann schon zu spät), da 
sich diese Werte fast alle beliebig fälschen oder  durchaus auch 
während einer Sitzung (IP, Host) ändern können.
II.) CRAM (Challenge-Response Authentication Mechanism)-ähnliche Verfahren
Hierbei wird bei jedem Aufruf ein einmaligs Token generiert, dass in 
einem Extra-Cookie beim Client gespeichert wird. Beim nächsten 
Aufruf gibt der Client das alte Token zurück an den Server. Der 
Server vergleicht, ob die Token übereinstimmen. Wenn sie
übereinstimmen, vergibt der Server ein neues Token. 
Wenn nicht, wird eine neue Session gestartet.
Theoriebedingt ist dies das höchste Maß an Sicherheit, dass man von 
einem aufgesetzten Session-Mechanismus erwarten darf. Dadurch, dass ein 
Token einmalig ist, muss der Angreifer sich beeilen, bevor ein neues 
Token generiert wird. Das macht es fast unmöglich, eine laufen Session, 
in der der berechtigte Client aktiv ist, zu übernehmen. Natürlich 
gehört auch dazu, alte Sessions möglichst schnell aus dem System zu 
werfen. 
Wie das geht, steht in der php.ini.