Session-Validierung

  • Über Twitter wurden wir darauf hingewiesen, dass LiveConfig anfällig für Session Hijacking sei, da keine Validierung der Session erfolge.


    Da die Antwort nicht in einen Tweet passt, mache ich das hier etwas ausführlicher. :)


    LiveConfig verwaltet seine Session-ID über die URL, da mehrere gleichzeitige Sessions mit dem selben Browser über Cookie-basierte Session-IDs nicht möglich sind.
    Wenn ein Angreifer die Möglichkeit hat, im Browser die Session-ID aus der URL auszulesen, dann könnte er genauso auch ein Cookie auslesen - die URL-Variante ist daher prinzipiell nicht unsicherer. Um zu verhindern, dass die URL durch ein Klick auf einen externen Link über den Referrer nach außen gelangt, sind alle externen Links innerhalb von LiveConfig durch einen Dereferrer geschützt.


    Da LiveConfig nicht anfällig für XSS (Cross Site Scripting) ist, besteht die einzige "Gefahr" also in einer bewußten oder unbewußten Weitergabe der URL mitsamt Session-ID (z.B. Screenshot, ...).
    Um diesem vorzubeugen, werden wir in der nächsten Preview-Version (1.1.4) ein zusätzliches Cookie mit speichern, welches die Verwendung der Session-ID auf den jeweiligen Browser begrenzt.
    Eine Begrenzung auf die IP-Adresse des Logins (bzw. einer /16 (IPv4) oder /64 (IPv6) Maske) macht unserer Erfahrung nicht immer Sinn; wir haben häufig den Fall erlebt, dass ein Nutzer mehrere verschiedene Internet-Uplinks gleichzeitig nutzt (Outbound Load Balancing), die in völlig verschiedenen Netzbereichen lagen.
    Wir werden dies aber als zusätzliche Option mit integrieren (die meisten Anwender haben ja nur einen Uplink ;))


    Weitere Vorschläge und Diskussionen sind herzlich willkommen.


    Viele Grüße


    Klaus Keppler

  • Gerade bei "normalen" Internetusern ist das durchaus wahrscheinlich, dass der Link weiter gegeben wird. Die meisten Nutzer denken sich bei Session-Parametern nichts, da sie diese größtenteils nicht erkennen oder auch gar nicht wissen, wofür dieser gedacht ist. Da LiveConfig aber genau auch für solche Benutzer gedacht ist (der eigentlichen "Kunde" mit Zugang zu LC), ist es auf jeden Fall sinnvoll detaillierte Überprüfungen einzubauen. Ich würde dabei soweit gehen, diverse Browsereinstellungen die im HTTP-Header mit übertragen werden immer mit den vorherigen zu vergleichen. Das ist auch kein 100% Schutz, aber besser als nichts. Ein zusätzliches Cookie ist natürlich auch nicht schlecht.


    Eine Option zur Überprüfung der IP wäre super, dann aber bitte je Benutzeraccount einzeln deaktivierbar machen, nicht nur für das ganze LC global :D



    MfG Christian

  • Ich würde dabei soweit gehen, diverse Browsereinstellungen die im HTTP-Header mit übertragen werden immer mit den vorherigen zu vergleichen.


    Eine Prüfung des "User-Agent:"-Headers ist in 1.1.3 bereits enthalten.


    Zitat

    Eine Option zur Überprüfung der IP wäre super, dann aber bitte je Benutzeraccount einzeln deaktivierbar machen, nicht nur für das ganze LC global :D


    Selbstverständlich. :)

  • Hallo,



    Da die Antwort nicht in einen Tweet passt, mache ich das hier etwas ausführlicher. :)


    Danke :)


    Zitat

    LiveConfig verwaltet seine Session-ID über die URL, da mehrere gleichzeitige Sessions mit dem selben Browser über Cookie-basierte Session-IDs nicht möglich sind.


    Macht auch durchaus Sinn, um somit gleichzeitig als unterschiedlicher User eingeloggt zu sein.


    Zitat

    Da LiveConfig nicht anfällig für XSS (Cross Site Scripting) ist, besteht die einzige "Gefahr" also in einer bewußten oder unbewußten Weitergabe der URL mitsamt Session-ID (z.B. Screenshot, ...).


    Mir fallen noch weitere Möglichkeiten ein:


    - Proxy-Caches/Logs
    - Internet-Cafes mit WLAN


    Zitat

    Um diesem vorzubeugen, werden wir in der nächsten Preview-Version (1.1.4) ein zusätzliches Cookie mit speichern, welches die Verwendung der Session-ID auf den jeweiligen Browser begrenzt.


    Klingt gut :)


    Zitat

    Eine Begrenzung auf die IP-Adresse des Logins (bzw. einer /16 (IPv4) oder /64 (IPv6) Maske) macht unserer Erfahrung nicht immer Sinn; wir haben häufig den Fall erlebt, dass ein Nutzer mehrere verschiedene Internet-Uplinks gleichzeitig nutzt (Outbound Load Balancing), die in völlig verschiedenen Netzbereichen lagen.


    Klar - auch AOL-Proxy-User dürften wenig begeistert von IP-Limitierungen sein.


    Allerdings war es etwas schockierend zu sehen, dass die simple Weitergabe der URL ("hier, schau mal!") plötzlich aus einem einfachen User einen Admin machte.


    Ansonsten bin ich auf die weiteren Tests und Funktionalitäten gespannt :)



    Viele Grüße,


    Anton Dollmaier

  • - Proxy-Caches/Logs
    - Internet-Cafes mit WLAN


    Das erledigt eigentlich die SSL-Verschlüsselung (HTTPS). Und wer die abhorcht (da gibt es ja auch Möglichkeiten, manche Firewalls machen das mit zwischengeschobenen SSL-Zertifikaten), der kommt ohnehin an alle Daten.


    Zitat

    Allerdings war es etwas schockierend zu sehen, dass die simple Weitergabe der URL ("hier, schau mal!") plötzlich aus einem einfachen User einen Admin machte.


    Mit "einfacher User" war aber nicht ein in LiveConfig eingeloggter User gemeint, oder? Denn die Session-ID ist immer an einen bestimmten Account innerhalb LiveConfig gebunden.


    Viele Grüße


    Klaus Keppler

  • Das erledigt eigentlich die SSL-Verschlüsselung (HTTPS).


    Ok, stimmt. Im Log/Traffic-Dump finden sich ja nur Hinweise auf die Domain/Server, nicht auf die tatsächliche URL.


    Zitat

    Mit "einfacher User" war aber nicht ein in LiveConfig eingeloggter User gemeint, oder? Denn die Session-ID ist immer an einen bestimmten Account innerhalb LiveConfig gebunden.


    War folgender Ablauf zwischen zwei Personen an unterschiedlichen Internetverbindungen und Browsern (Firefox/Chrome).


    - Person A loggt sich mit User A ein
    - Person B loggt sich mit User B ein
    - Person B gibt eine URL an Person A weiter: "/liveconfig/servers/manage?id=MxHGNnvy1i6aMKGjDsoie6qZ"
    - Person A ruft diese URL im Browser auf und hat nun die vollen Rechte von User B
    - im zweiten Tab ist immer noch die Session von User A aktiv und nutzbar, da andere Session-ID


    Funktionierte auch andersrum mit "/liveconfig/admin/account/contact?id=6pqjZCwf1cgiYhG0WVkVZZLu".


    Und das sollte eigentlich nicht passieren.


    Oder bin ich nur zu paranoid? :)

  • Hallo,
    dieses Problem mit den Sessions kommt mir bekannt vor, es gibt ein VServer-Interface welches auch mit Sessions arbeitet, welche man kopieren kann bzw. konnte. (Habe nach Meldung jedoch nicht wieder getestet, da ich es nicht angeschafft habe.)
    Ich werde demnächst auch einen Testserver aufsetzen und Liveconfig etwas mehr testen.
    Grüße
    Martin Ickert

  • In v1.1.4 ist die Session-Verwaltung bereits abgesichert: jeder Nutzer erhält zusätzlich zu seiner Session-ID (in der URL) ein Cookie. Dieses ist wiederum Multi-Session-fähig, d.h. man kann in einem Browser mehrere verschiedene Sitzungen zu LiveConfig geöffnet haben; auch ein Logout aus einer der Sessions beeinflusst die anderen Sessions nicht.
    Das Cookie wird nur serverseitig genutzt, dank "HttpOnly"-Flag ist es in den meisten Browsern vor JavaScript-Zugriff geschützt und bietet somit noch mehr Schutz gegen XSS.
    Session-Hijacking sollte somit praktisch unmöglich sein.


    Viele Grüße


    Klaus Keppler

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!