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
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
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.