[Powie\"s PSCRIPT Forum] Session Hijacking Vulnerability

Begonnen von , 15. Oktober 2004, 23:46:25

Vorheriges Thema - Nächstes Thema



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.

Rechtschreibfehler sind wie immer beabsichtigt und dürfen wie immer behalten werden /uploads/emoticons/icon_e_biggrin.gif.40dcc5d69f84e2cf29e77d8e1e9a84e2.gif\" alt=\":D\">




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.  




all your base are belong to us